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For the 

new generation, 
a new choice in 
VM systems 
management. 


For a company the size of PepsiCo, 
it takes a lot to keep the sparkle 
in your data processing operations. 
From Pepsi-Cola to Taco Bell, 
growing user demands have made 
strong central systems manage- 
ment essential. 

Fortunately, as the challenge 
has grown, so has PepsiCo’s 
ability to meet it— thanks to 
VM Software and the capabilities 
of VMCENTER II. 

The results: a new performance 
standard for VM operations. A 
new level of convenience for 
data center staff. And a new ability 
to manage for the long term— 
knowing the short term is under 
control. 


LEARNING THE VALUE 

OF RELIABILITY. 

At one time, the company relied 
extensively on in-house software 
for data center management. 
Saving some money up front. But 
quickly paying the price in flexi- 
bility, reliability, and peace 

of mind. 

Today, more and more opera- 
tions are under VMCENTER 
control. And the results are 
© 1987 VM Software, Inc. 
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VMCENTER II 
Smart Economics. 


apparent in everything from 
backup and tape management to 
system scheduling and accounting. 
Performance and reliability are 
up. Operator errors and adminis- 
trative headaches are down. While 
problem resolution is faster, 
easier, and more accurate than 
ever before. 


VMCENTER II. THE VM 
SYSTEMS MANAGEMENT TOOL 
FOR THE FUTURE. 

This performance is impressive. 


But it’s only the beginning of 
what VMCENTER II can do. From 
comprehensive management 
reports to the automated handling 
of a broad range of everyday 
operations, VMCENTER II does 
more for VM systems management 
than any other product on the 
market. Which is why it’s the one 
essential complement to ail your 
VM systems — from 9370 to 3090 
to whatever the future may bring. 
VMCENTER II. Standard-bearer 
for Pepsi’s new generation. 
Smart solution for today. For more 
information, write or call: 


800-562-7100 
703-264-8000 


VM Software, Inc. 
1800 Alexander Bell Drive 
Reston, Virginia 22091 


SOFTWARE INC. 
The VM Experts 
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A le (Ps 
Still screaming / 
+ bout why 
/ CICS failed? 


Get the answer faster than you 
can print a system dump. 

Eyewitness™ gives you online 
diagnostics instantly, so you can 
debug storage violations, CICS sys- 
tem abends, and operator cancels— 
fast. It even slashes dump time and 
downtime by up to 90%! There’s no 
other product like it. 

In just two months, Eyewitness 
helped over 75 data centers solve 
their CICS mysteries. Imagine...No 
more waiting for the dump to print. 
No more reams of paper. No more 
agonizing hours searching hex code 
for clues. And now, if you need level 
2, you'll know it! Best of all, 
Eyewitness bears the signature of 
Landmark Systems Corporation, 
makers of The Monitor for CICS.™ 

Eyewitness is revolutionary! See 
for yourself. Call us today fora 
FREE, 30-DAY TRIAL at 1-800- 
227-8911 or 1-703-893-9046—and 


scream no more. LANDM Ark’ 


"SOLVE THE MYSTERY 


Landmark Sys s Corporation 
8000 Tower. scent Drive 
Vienna, Virg' 22180-2700 
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COVER: 

The graphics on the cover 
represent a computer 
simulation of how atoms of 
molten glass might appear 
when cool. The ES/9370 at 
Corning Glass Works 
generated the model in 
partnership with a 3090. 
Computer modeling allows 
researchers to simulate 
effects on the substances that 
comprise their products. 
See article on page 34. 
Photograph courtesy 
of IBM. 
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Local Shared Resources In CICS 

LSR has a positive influence on both performance and resource 
utilization and as such is one of the most important performance tools 
available in a CICS environment. By Ted C. Keller 


Why COBOL Efficiency Still Makes Sense 

Techniques enabling an IBM mainframe COBOL program to run faster 
are presented with coding suggestions to motivate you to examine new 
techniques. By Harvey Bookman 


DB2’s Query Management Facility: One User’s Experience 

The author's mission when she joined Diamond Shamrock Chemicals was 
to provide micro and mainframe user tools and support to complement 
existing production systems. QMF was found to be a user-friendly 
product. By Mary Jo Cater 


ES/9370 And VM Generate Computer Simulations 

Corning Glass Works gains a cutting edge in glass modeling by 
combining the ES/9370 and the 3090 to simulate effects on the substances 
that comprise Corning’ s products. By Stephen H. Quanrud 


ISPF Techniques 

Techniques that aid in making the use of the Interactive System 
Productivity Facility/Program Development Facility more productive are 
described in this article. By Jon E. Pearkins 


ESA Implements Expanded Addressing 
Enterprise Systems Architecture implements expanded addressing through 
new facilities known as the Advanced Address Space Facility (AASF). This 
article presents more information about several of these facilities. 
By Michael Haupt 


DB2 REORGS? Don’t Waste Your Time! 

IBM designed the DB2 REORG utility to correct the problems caused by 
disorganized data. Read this article to discover what this utility is and how 
it can be improved. By Bill Cunningham 


Capacity Planning: The Applications Development Viewpoint 

This author feels applications developers should contribute to the 
capacity planning process by finding and accounting for NBUs that relate 
in a linear fashion to computer resource consumption. By Michael Snyder 


Applications Development: 
A Guide Through The Maze Of Tools And Methods 
Organizations, not just system development managers, need to adopt 
procedures for weighing each new development tool's promise against each 
project's realities and for predicting obsolescence. 
By Robert Lorentzen and Paul Tinnirello 


Banking Consortium Solves Disaster Recovery Dilemma 

The president of the data processing subsidiary of a $1.8 billion bank is 
responsible for smooth handling of data regardless of the circumstances. 
This is the story of how he did just that. By Beth Ellyn Rosenthal 


Capacity Surfaces 

The capacity surface offers the analyst a vehicle for communicating large 
quantities of complex modeling results to decision makers. By H. Pat Artis 
VSE Under The Covers: The Dispatcher And Scheduling System 

This article offers an in-depth explanation of the supervisor’s interrupt 
and scheduling mechanism in the VSE system. By Eric L. Vaughan 
VSAM Optimization And Design 

Free space selection, I/O buffer allocation, space allocation and index 
options are addressed in this article. By Eugene S. Hudders 


Capacity Planning Using Statistical Theory And Performance Data 
The theories presented in this article are the basic mathematical premise 
for a total tuning philosophy. By Philip C. Davis, III 
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With Cache Magic, improved VM system performance has 
never been easier. Enjoy a dramatic reduction in batch run 
times, in some cases by as much as 50%! Accelerate online 


response times, and complete more transactions in the same, or 
less time — all without the cost of additional hardware! 


Cache Magic works its magic by storing your most active DASD 
files in an in-memory cache. Here they are accessed at proces- 
sor speed, effectively eliminating |/O bottlenecks. And because 
Cache Magic automatically determines which files should be 
cached, performance gains are guaranteed, without investment 
of time and personnel. 


Why not spend ten minutes with one of our representatives to 
find out what amazing things Cache Magic can do for you? All 
you have to lose are batch overruns, user complaints, and 
expensive hardware upgrades. 


20 Years of Software Innovation 
1 (800) 537-1969 (415) 572-1200 
In Europe: +31 10 436 12 77 
® 1700 South El Camino Real, San Mateo, CA 94402 
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|) eee was the month of 
accidents of the bone-breaking, 
muscle-wrenching kind. First my 
eight-year-old son injured his 
knee and pulled the hamstring of 
his left leg at a roller skating 
party. The pediatrician sent him 
to the orthopedic surgeon and 
while no bones were broken, he 
was on crutches for a while. 

Then, my teenage son was 
running backward during an athletic drill, hit a wet spot and started to fall. 
Thinking he could break his fall, he put his hand out. He broke his fall and 
a bone in his hand. 

Sometime in between my sons’ accidents, I sprained my ankle. Rather, 
I thought I sprained my ankle. It hurt like crazy when the accident happened, 
but I thought it was just bruised. The first inkling that it was more than a 
bruise came about two-and-a-half weeks later when I realized the injury 
was not getting any better. In fact, it was worse. You guessed it. I have a 
hairline fracture of my left ankle bone. 

The only way I have peace of mind about such a series of bizarre accidents 
is because I have insurance. With insurance comes the knowledge that when 
an accident happens, I will be able to get the proper attention and institute 
a recovery plan so that I will be ‘‘up and running”’ in no time. 

Insurance is to an accident as a recovery plan is to a disaster. 

A disaster might be natural such as a fire, flood, earthquake or tornado. 
Also, it could be the result of a terrorist bomb. Closer to home, a downed 
computer could spell D-I-S-A-S-T-E-R. 

An adequate recovery plan can restore computer services within 48-hours. 
It would involve two emergency locations provided to recover the computer 
system. First there is the fully-equipped disaster recovery facility from which 
regular daily computer processing runs. It usually is available for around 
six weeks. At this facility, the staff would load the operating system so it 
would be ‘‘up and running’’ when the subscriber to the plan arrives to load 
the application. 

If recovery time is longer than six weeks, the plan provides for a shell 
facility in which computer operations and support staff would be available 
for about six months. 

One subscriber to a fully-equipped disaster recovery facility described it 
as “‘sleep insurance.’’ Two excellent reasons for being a subscriber to such 
a facility are to maintain the company’s operation and its computer base. 

In this issue is a story starting on page 63 about a banking consortium 
and how it solved its disaster recovery dilemma. It may be the impetus you 
need to urge your company to look into a recovery plan. In the event of an 
accident or disaster, we all need a plan to get us ‘‘up and running.’’ 

This issue also covers another area of planning — capacity planning. 
Capacity planning from the application development viewpoint starts on 
page 54 and is written by Michael Snyder. Phil Davis writes about capacity 
planning using statistical theory and performance data starting on page 84. 
We are particularly pleased to welcome Pat Artis back as he tackles the 
problem faced by performance analysts of how to effectively convey the 
results of their systems’ performance on page 68. Planning pays off! 

A membership that more than pays for itself in technical information 
passed on to users is one with GUIDE International. We have had an over- 
whelming response to Pete Clark’s article, “GUIDE International: A User’s 
Perspective,’’ that appeared in the January, 1989 issue from readers wanting 
information about how to become a member of GUIDE. To do this, contact 
Margaret Miller at GUIDE International Corporation, 111 East Wacker Dr. , 
Suite 600, Chicago, IL 60601, (312) 644-6610 Ext. 3216. 


Corl M. Rong 


Carol M. Hoag 


a 


ell 


=|) 


, MAINFRAME JOURNAL 


For Users of IBM Systemn/370 Architecture & Compatible Systems 


ae 


Publisher and Editor-in-Chief 
Robert H. Thomas 


Associate Publisher 
Martha Thomas 


Editor 
Carol M. Hoag 


Copy Editors 
Judy Beller 
Pat Warner 


Art Director 
David Kramer 


Assistant Art Director 
Ken Buerer 


Advertising Manager 


Denise Thomas 


Marketing Services 
Sally Webb 


Circulation Manager 
Janice Porter 


Assistant Circulation Manager 
Nancy Crawford 


Administrative Manager 
Marian Davenport 


Typography Coordinator 
Dub Pope 
Jaggars Chiles Stovall 


Printing Coordinator 
Steve Priester 
American Signature Graphics 


BPA Membership 
Applied For April, 1988. 


SUBSCRIPTION RATES & IN- 
QUIRIES: Subscriptions are free within 
the USA and Canada. One-year foreign 
subscriptions are $96. 

All subscriptions, remittances, re- 
quests and changes of address should 
be sent to MAINFRAME JOURNAL at 
10935 Estate Lane, Suite 375, Dallas, 
TX 75238, (214) 343-3717. 


MAINFRAME JOURNALS? is copy- 
righted 1989. All rights are reserved. 
Reproductions in whole or part prohib- 
ited except by permission in writing. 


February 1989 


Why We're Betting 


At SAS Institute Inc., we've invested 
more than 10 years of research—and 
over a million lines of code—in the 
SAS® System, the world’s leading data 
analysis software. So you can bet we 
left nothing to chance when we chose 
the C language for the next generation 
of our software. 

We selected C for the portability it 
would bring to the SAS System, but 
weren't about to risk our code on just 
any mainframe C compiler. So we tried 
them all. When none could meet our 
exacting requirements, we created our 
own: the SAS/C compiler. 


We Developed It. 
Support It. Use It. 


The SAS/C compiler set new standards 
for efficiency and technical quality, with: 
=== A source-level debugger that 
includes structure display, ABEND 
recovery, and debugger 1/0 exits for 
debugging specialized applications 

== Reentrant object code 

=== Highly optimized generated code 
== Use of standard IBM linkage 
conventions, with support for 31-bit 
addressing 

== A CMS Rexx/TSO CLIST interface 
= Support for signal handling 
including program checks and terminal 
interrupts, and non-standard signals 
such as timer interrupts and stack 
overflow 

== Many built-in functions including 
string handling 

= |n-line assembler. 


SAS is a registered trademark of SAS Institute Inc., 
Cary, NC, USA. SASIC is a trademark of SAS Institute. 


Copyright © 1987 by SAS Institute Inc. 
Printed in the U.S.A. 


And when we combined these 
features with outstanding technical 
support and frequent updates —both 
provided free—software developers 
everywhere took notice. The SAS/C 
compiler is now the market leader, 
installed in hundreds of commercial 
firms and academic institutions. 


Test It. Compare It. 
FREE for 30 Days. 


We're betting you've set the same 
high standards. That’s why we’d like 
to send you the SAS/C compiler, under 


Using a C version of the 
Dhrystone benchmark, the 
latest SAS/C compiler 
release produces the fastest 
code among the top 3 
mainframe compilers. It even 
tops our own previous 
release by 35%. 


SAS/C 3.01 


Waterloo C 


IBM C 


a Million Lines of Code on 
the SAS/G Compiler. 


OS or CMS, for a free 30-day evalua- 
tion. We'll also send you a free copy 
of a leading benchmark program. Com- 
pare our compiler with any other. Odds 
are, you'll choose the SAS/C compiler. 

Just mail the coupon below. Or call 
your Software Sales Representative at 
(919) 467-8000. 


SAS Institute Inc. 

SAS Circle 1 Box 8000 

Cary, NC 27512-8000 

Phone (919) 467-8000 
® Fax (919) 469-3737 


Average Loops Per Second 
Mainframe C Compilers 


I'd like to put the SAS/C™ compiler to the test with a free 30-day trial, and 
my free copy of the Dhrystone benchmark program. Give me the details. 


Please complete, or attach your business card. 


Name Title 

Company 

Address 

City State ZIP 
Telephone 


Mail to: SAS Institute Inc., Attn: CC, SAS Circle, Box 8000, 


Cary, NC, USA, 27512-8000 


Q I've inherited a system in which Generation Dataset Groups 
(GDGs) were created in an uncontrolled manner. Is there a 
way to inquire what GDGs are in the system now, the retention 
period and when the GDG was defined? 


A Getting the information you need is strictly a manual proc- 
ess. First, do an IDCAMS LISTCAT USERCATALOG to get 
the name of all of your user catalogs. Then do a LISTCAT 
ALL CATALOG (usercatalogname) for each of your user cat- 
alogs. This will give you the name, creation date and LIMIT 
(number of generations) of the GDGs. 


Q We run DOS/VSE as a virtual machine. Whenever someone 
leaves our IBM 3287 printer not ready, we get message 
DMKDID 5461. If not corrected by readying the printer, it 
causes us to have to re-IPL DOS/VSE. Any ideas? 
A From the information we have available to us, I am assum- 
ing your TP-monitor (CICS or something else) appears to be 
hung up on a missing interrupt from the 3287 that in turn hangs 
your entire system. (This type of error was common under 
BTAM by the way.) I would suggest looking at the SYSMIH 
value. Either set it to zero to ignore the missing interrupt or 
set the value high enough to allow you to ready the printer 
before the error occurs. Also, check to see if you have the 
MIH option specified in your user directory entry. If you do 
not have it specified, CP will not simulate an interrupt to the 
guest when a missing interrupt is detected. 

We assumed some information in answering this question. 
Some additional information you may need to find the solution 
to this problem is: 


@ What is your release of VM? 

@ What is your release of VSE? 

@ What is the entire message? 
DMKDIDS46I has the following content: 
DMKDIDS46I Interruption (Pending/Cleared); (Device/ 
Control Unit) RDEV, CSW csw, USERID userid 

@ What is your TP monitor, BTAM or VTAM? 

@ What is the SYSMIH value for MISC set to? 

®@ Do you have MIH set in the User directory entry? 


Q May I put freespace on an index component to reduce the 
number of Control Interval splits I have been getting? I'm 
running MVS/XA using DFP 2.3 and I would like to cut down 
the number of splits on the index of a VSAM file that gets heavy 
inserts. I tried putting freespace on the index component when 
I redefined the file, but it looks like VSAM will not let me do 
it. Is this right? 

A That's right. VSAM will not allow you to define an index 
component with freespace. There are a couple of reasons for 
this. The main reason is that freespace applies to a percentage 
of an entire Control Interval. Each Index Control Interval con- 
tains just one record that VSAM makes seven bytes less than 
the size of the Index Cl. VSAM will not reserve part of an 
Index Control Interval because then it could never fit an index 
record into one. 

The other reason is that if VSAM allowed freespace on an 
Index record, then part of each Data Control Area referenced 
by the Index could not be loaded with data. You would in 
effect be applying freespace to each Data Control Area inad- 
vertently. It is preferable to request the data freespace directly. 

Instead of using freespace, we recommend expanding the 
size of each Index Control Interval when you define the file. 
Beginning with DFP 2.2, VSAM allows Index CI sizes up to 
32K. (For VSE, you can go up to 8,192 for the index.) Simply 
specify an Index Control Interval size larger than the default 
value VSAM selected for you. Expanding the Index CI should 


reduce the splits and may also help with key compression prob- 
lems and reduce the total number of index records and levels. 

The disadvantages are that each index record will use more 
virtual storage when read into memory, rotational delay and 
I/O transfer times will increase and your new index size may 
not match available CICS LSR buffer pool sizes. 


Q What are IBM's plans for VM? What enhancements will be 
added in future releases? 


A [am sure there are many data processing professionals who 
have this same question on their minds. IBM has a way of 
keeping these things secret until IBM is ready to let us know 
about them. The best I can do is pass on to you some infor- 
mation and speculation that has passed over my desk or things 
I have heard at user groups. 

Some of the things you could look for in the future are the 
following. 


@ The CLASS OVERRIDE table may be dynamically 
changeable in the future. 

® A disposition parameter for the VM print queue similar to 
the VSE POWER parameter ‘DISP=K’ may be intro- 
duced in the future. 

= A maintenance history file has been announced for VM/ 
SP R6. This will be similar to the MSHP history file in 
VSE. This has been long in coming but will be a nice 
feature for VM. 

@ VM may be given the ability to cold start without clearing 
the queue areas. 

@ Look for more products to utilize GCS. Networking tools 
for VM could be big in the future also. As we all know, 
networking of different computers will be the challenge 
of tomorrow. 


I would ask your IBM representative if he/she knows any- 
thing that can be passed on to you. Sometimes the represen- 
tatives hear things that can be passed on to a customer. 


Q We use VM/SP Release 4. There are several programs 
available for CMS Release 5 (University of Waterloo) that were 
very useful. I need to convert these programs to SP. Has any- 
one already done these conversions? If so, where can I get 
copies? Alternatively, | need better information that IBM pro- 
vides on the differences between the old CMS file system and 
the new. 


A The best way to find out if anyone has already converted 
these programs would be to contact the University of Waterloo 
or the program’s author. Since they distributed the program 
tape, they may know if someone has already converted the 
programs you are interested in. It is our understanding that the 
University of Waterloo tapes contain the names and addresses 
of the program authors and the University of Waterloo con- 
tacts. 

With regard to the second part of your question about the 
differences between the old CMS file system and the new, we 
believe IBM will be your best source of information on these 
changes. 

If you decide to change the programs yourself, you should 
examine the source of these programs and determine if the 
author used standard VM calls and parameters or if he hard- 
coded the process. If standard calls and macros were used, you 
should be able to reassemble the programs using the VM Re- 
lease 4 assembler. Should the programs contain non-standard 
calls, then you will have to rewrite the modules so they work 
on your system. The program author may be able to assist you 
if a rewrite is needed. 
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SYSTEMS SOFTWARE FOR VM/VSE DATA CENTERS: 


Only one company covers the two, 
completely. 


Computer Associates introduces: 
CA-UNICENTER/I1 VM Gnd CA-UNICENTER/II VSE, 
the industry's only complete line of VM/VSE 
systems software that automates every 
major area of the data center. 

Now, true compatibility among the VM 
and VSE components. Equivalent products 
for both environments offer the VM/VSE data 
center unparalleled advantages such as: a 
common catalog that simplifies tape 
management, security software that protects 
all data in your installation, job accounting 
information that is collected for activity in 
both VM and VSE, and much more. 


Only Computer Associates provides com- 
mon interfaces and full integration to give 
you unprecedented control, from a central 
point, over both environments. 


And only Computer Associates offers 
CA-UNISERVICE®/II, a secure link between your 
mainframe and CA’s Customer Service System, 
24 hours a day. You get online access to 
software fixes, interactive problem resolution, 
product tutorials and more. No one else has 
anything like if. 


Call Dana Williams today: 
800-645-3003 (Ext. 5802). 


OMPUTER' * World's leading independent software company. 


* Broad range of integrated business and data processing 


1SSOCIATES software for mainframe, mid-range and micro computers. 


Software superior by design. * Worldwide service and support network of more than 100 offices. 


Resource & Operations Management « Financial * Banking * Graphics « Spreadsheets « Project Management 
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APPLICATION 
INTEGRATION 
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Windowing is one way to integrate your applications with TPX. 
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End users can also benefit from interacting with multiple applications on a single. 
customized screen. 


ONLY TPX 


MAKES IT THIS 


EASY 


Session managers allow users to switch among 
applications, but what do users do when they 
need information from two or more applications 
at the same time? TPX, the world's leading 
session manager, now sets a new standard for 
session management by providing Application 
Integration—easily. 


Many times every day your users need to access 
and update information from multiple applica- 
tions concurrently. For instance, a service repre- 
sentative using a Customer Information 
application under IMS sees a customer's name, 
address and a summary of accounts. While 
viewing this data, the service representative 
needs to access detailed information from the 
Account History application running under CICS. 
Think of the increased efficiency and improve- 
ment in customer service if information from 
two or more related applications could be com- 
bined ona single, interactive screen. 


TPX gives you two ways to integrate applica- 
tions: windows and customized multi-application 
screens for end users. With windows, you can 
divide the terminal screen any way you want 
and easily interact with any session, as well as 
jump, scroll, zoom and do cut and paste be- 
tween sessions. If that’s not enough, you can 


customize your own screens by combining data 
from any number of applications and give your 
users a unified, standard view no matter what 
the existing application screens look like. 


Either way, TPX integrates concurrent applica- 
tions easily, increasing your users’ productivity 
and your business’ competitive advantage. 


Return the attached reply card today for more 
information on how TPX 2.0 can help you inte- 
grate your applications in an MVS or VM envi- 
ronment. If someone else already returned the 
card, feel free to call (800) 323-2600 ext 444 or 
(412) 323-2600 ext 444 in PA. 


DUQUESNE 
SYSTEMS 


Two Allegheny Center 
Pittsburgh, PA 15212 
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Work with BMC 


DB2 can be a lot more work than you expected with 
quite a bit less help than you need. But when you’ve 
got BMC Software’s comprehensive set of data base 
administration tools—which include standard inter- 
faces and integrated function—you can reduce your 
costs and make your work fast, easy and error-free. 


DB2 ALTER—provides complete support for changing, 
copying and migrating DB2 data structures; includes 
data conversions, authorization-id switching and 
restart capabilities. 

DB2 CATALOG MANAGER- gives quick and easy 
catalog information, execution of SQL DDL and DB2 
utilities, audit logs and extended SQL function. 

DB2 DASD MANAGER-—controls the life cycle of phys- 
ical objects with comprehensive space analysis statis- 
tics; also includes space estimation, AMS command 
and utility jobstream generation and action triggers. 
DATA PACKER™/DB2—reduces DASD requirements for 
DB2 tables an average of 50% to 70%; reduces EXCPs. 
DB2 REORG PLUS-—reorganizes DB2 tables 4-10 
times faster than the supplied DB2 utility; provides dual 
image copy and statistical history. 


For more information or to begin a 30-Day-Plus Free 
Trial of any or all of these products, complete and 
return this coupon or call BMC Software, Inc., 

The Complete DB2 Company.™ 


Pom ee ee ee eee a--=-- 


BMC Software, Inc. 
rn E>)]\/ I 
1-800-841-2031 SOFTWARE 


or call collect: 713-240-8800 


Contact me about: 
Free More 
Trial Info 
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All BMC DB2 products 


Name 


Title 


Company 


Address 


City State/Prov. Zip/P.C. 


Phone 
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Local Shared 
Resources 


In CICS 


LSR has a positive 
influence on both performance and 
resource utilization. 


ne of the most significant per- 
() imme tools available in a CICS 

environment is VSAM _ Local 
Shared Resources (LSR). LSR provides 
services that can allow savings of CPU 
processing, virtual storage utilization, 
working set size and physical I/Os. Many 
tuning techniques require trade-offs be- 
tween resources — you often need to 
spend more of one resource to reduce uti- 
lization of others. 

LSR, compared to Non-Shared Re- 
sources (NSR), can allow for improve- 
ments in performance as well as reduc- 
tions in usage of all these resources 
simultaneously. In performance terms, this 
is one of the few true ‘‘win-win’’ situa- 
tions. In most cases, LSR has a positive 
influence on both performance and re- 
source utilization. 

LSR and NSR are the two access tech- 
niques commonly used with VSAM. NSR 
is more common and is available without 
any special support. It is used primarily 
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by batch programs and other less sophis- 
ticated systems. LSR is more complex and 
its use is usually limited to systems pro- 
viding this special support. CICS pro- 
vides support for both LSR and NSR. For 
CICS Releases 1.7 and beyond, LSR is 
used by the default. 


NSR Processing 


When a VSAM Keyed Sequence Da- 
taset (KSDS) file is accessed using NSR, 
VSAM will need to read the highest level 
of index, any additional levels of index, 
the sequence set (which is the lowest level 
index) and finally the Control Interval (CI) 
containing the data. VSAM will reserve 
one index buffer and one data buffer for 
each string defined for the file. It will also 
reserve an extra data buffer for internal 
uses. If more index buffers are allocated 
than VSAM strings, VSAM will use these 
extra index buffers to hold the highest level 
index CI and additional high-level index 
Cls (if any). 


On subsequent I/O operations, VSAM 
will look at the CIs in these buffers before 
attempting to reaccess high-level index 
records from the file. When only one ad- 
ditional buffer is allocated, it will be used 
to hold the highest level index record. 
Most small- to medium-size VSAM files 
have only this single high-level index re- 
cord. Larger files may have additional 
levels of index and can benefit from ad- 
ditional index buffers. 

When a sufficient number of index 
buffers are allocated with NSR files, the 
physical I/Os to read higher level indexes 
can be all but eliminated. Accessing data 
on the file will normally consist of locat- 
ing the higher level indexes in memory, 
reading the sequence set CI from DASD 
and reading the data CI. If the specific 
index buffer that is allocated to the VSAM 
string assigned to read the sequence set 
CI happens to contain the correct CI (it 
was left there from the previous access by 
that string), the CI will be used without 
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reaccessing it from DASD. Similarly, if 
the specific data buffer that is allocated to 
the string assigned to read the data CI 
happens to contain the correct data, a read 
operation will be bypassed. 

In most environments, the number of 
times the sequence set or data Cls will be 
found in the correct buffer will be so small 
that it is not worth considering. Further- 
more, if no extra index buffers are allo- 
cated, each level of index will be read one 
at a time into the same buffer thereby 
guaranteeing that no I/O can be saved. 
Typically, additional index buffers will be 
allocated and each read access to a VSAM 
KSDS using NSR will involve two I/O 
operations — one to read the sequence 
set CI and one to read the data Cl. 


LSR Processing 


When accessing VSAM files via LSR, 
one or more pools of buffers will be cre- 
ated. In most cases, several files will share 
buffers in a pool. Buffers in the pools are 
not permanently assigned to strings as- 
sociated with specific files but can be uti- 
uzed by different files in the pool. Each 
pooi is divided into subpools. Each sub- 
pool contains a set of buffers of one par- 
ticular size. CICS allows us to specify 
which LSR pool a file will use. Within 
each pool, data and index components are 
assigned to different subpools based on 
their CI sizes. 

When a record is accessed using LSR, 
VSAM needs to look at each of the high 
levels of index, the sequence set and the 
data CI just as it did with NSR. With 
LSR, however, before assigning buffers 
or doing I/Os, VSAM will determine if 
any buffer in the proper subpool contains 
the CI to be read. If one does, data in the 
buffer will be used without rereading the 
CI from DASD. This feature is called look- 
aside. 

With LSR it is not only possible to avoid 
reading high-level index records but in 
most cases it is probable that a high per- 
centage of the sequence set Cls will also 
be located via the look-aside feature. With 
look-aside, it is not uncommon to satisfy 
80 to 95 percent or more of all requests 
for index data using Cls already in the 
pool. The exact read/hit ratio will depend 
on a number of factors discussed below. 
(The term, read/hit ratio, will be used to 
denote the ratio of CIs located using look- 
aside to total read accesses requested.) 

While it is likely that a fairly large per- 
centage of index records will be in the 
pool when they are needed, a consider- 
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ably smaller percentage of data CIs will 
be available in the pool. This is because 
there are usually many times more data 
CIs in a VSAM file than index CIs. De- 
pending on data access patterns, LSR may 
provide various levels of I/O access sav- 
ings for data Cls. 

VSAM maintains the LSR pool using 
a Least Recently Used (LRU) algorithm. 
Whenever a record needs to be read from 
DASD, LSR will select the buffer that has 
been referenced least recently. This, in ef- 
fect, tends to keep those buffers in mem- 
ory that have been referenced most re- 
cently and that are most likely to be read 
again shortly. Those Cls that are refer- 
enced frequently (such as high-level in- 
dex records) will tend to remain in the 
pool. Lesser-used data will normally need 
to be reaccessed from DASD each time it 
is needed. The amount of benefit LSR can 
provide depends on the size of the pool 
(the number of buffers) and specific ac- 
tivity against files sharing the various sub- 
pools in the pool. 

A typical access to an active VSAM 
KSDS would proceed roughly as follows. 

1. VSAM would attempt to read the 
highest level index record and then other 
higher level index records (if any). There 
is a high probability that all these CIs 
would be resident somewhere in the proper 
subpool and I/O operations usually will 
not be required. A read/hit ratio of 95 
percent or better should be expected for 
high-level index data in a tuned LSR sub- 
pool. 

2. VSAM will then attempt to read the 
sequence set CI. Depending on the size 
of the file, the number of buffers in the 
pool and the activity of other files sharing 
the pool, it is reasonable to expect that a 
fairly large percentage of sequence set Cls 
will be found in the subpool. This will be 
particularly true of files in which a high 
percentage of the activity falls in a rela- 
tively narrow key range. 

3. Finally, the data CI will be accessed. 
On a relatively small file containing highly 
active reference data, 80 percent or more 
of the data CIs requested may be in the 
pool when they are needed. On larger files 
in which data tends to be reaccessed 
quickly (for example, a clerk working a 
number of transactions for the same city 
in a city file), it is also possible to have 
a good data read/hit ratio — perhaps as 
high as 70 to 80 percent. Larger files with 
truly random access patterns may have a 
much smaller data read/hit ratio because 
of the small probability that CIs will be 
in the pool when they are needed. 


Of the three read operations necessary 
to access a VSAM KSDS file with one 
high-level index, LSR may often average 
less than one physical I/O per logical ac- 
cess. For small, highly active files, it is 
reasonable to expect a read/hit ratio of 90 
percent or better overall. With similar files 
accessed via NSR, the high-level index 
could be retained in memory, but each 
access would average almost exactly two 
physical I/O operations (usually one for 
the sequence set CI and almost always 
one for the data CI). 

While LSR could average as few as 0.3 
physical I/Os per access, NSR could do 
no better than about 2.0. For larger files 
or files with more random access patterns, 
LSR would achieve a somewhat lower 
read/hit ratio and smaller percentage of 
1/O savings. And, for very large files with 
multiple high levels of index, LSR might 
achieve a combined read/hit ratio for in- 
dex and data Cls of only 50 to 60 percent 
unless some tuning was done. 


Limitations When Using LSR 


Most specific limitations to the use of 
LSR have been eliminated by Release 1.7 
of CICS and most VSAM files should now 
be eligible for inclusion in LSR. How- 
ever, there are a few situations in which 
LSR will either cause problems or not 
perform as well as NSR. 

Perhaps the greatest problem associ- 
ated with placing a file in LSR is that 
certain programming practices can cause 
program lock-ups or data contention. 
When using NSR, a single task can access 
multiple records on a single file concur- 
rently. The CICS command level inter- 
face will allow a task to both browse a 
file and perform updates or deletes on the 
same file without ending the browse op- 
eration. With NSR the VSAM update op- 
eration does not interfere with the browse. 

With LSR, though, VSAM will first 
determine if the CI being accessed is al- 
ready in the pool. If it is and is in use 
(that is, it is being held for an update or 
browse operation), VSAM will have the 
requesting task wait until the buffer be- 
comes free. If that same task is holding 
the buffer, the task will become locked 
up. It will be waiting for the release of a 
resource that it owns itself and cannot free. 
The task will remain waiting until it is 
cancelled. This can lead to additional 
complications if other CICS tasks need 
any of the resources held by that task. 

With LSR, it is important that appli- 
cations refrain from accessing multiple 
records on the same VSAM file concur- 
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rently. Even when records with different 
keys are accessed, if they both are located 
in the same Cl, a lock-up will occur. 
For these same reasons, it is important 
that CICS tasks retain control of LSR 
buffers no longer than necessary. Since no 
other task can access data in a CI until it 
is released, it is important to design ap- 
plications with this in mind. It goes with- 
out saying that records read for update 
should be rewritten, deleted or released 
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as quickly as possible. (This is also true 
for NSR processing. ) 

With LSR it is also important to pre- 
vent browse operations from holding a 


particular Cl for prolonged periods of 


time. Some examples of situations to be 
avoided would include not ending a 
browse during segments of a conversa- 
tional task or updating other files before 
ending a browse. In either case, records 
in the CI being browsed will be unavail- 
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able to other CICS tasks until the CI is 
freed. 

Files that are browsed heavily may be 
better serviced by NSR than LSR. Browse 
operations under NSR may benefit from 
read-ahead processing. If extra data buff- 
ers are defined for a file using NSR (more 
than one data buffer per string plus the 
extra data buffer that VSAM reserves for 
its own use), the first task starting a browse 
operation will allocate all of the extra 
buffers for read-ahead processing. It will 
schedule multiple chained I/Os and at- 
tempt to fill the buffers with data before 
it is needed. Any other browse operations 
starting while these buffers are being used 
will use a single data buffer each. Thus, 
one string at a time can benefit from read- 
ahead processing with NSR. All other 
strings will use only one data buffer. With 
LSR, all browse requests use one buffer 
at a time and there is no read-ahead. But 
if the CI to be read happens to be in the 
pool already, it will not have to be reread. 

Perhaps the most significant problem 
using LSR for files that are heavily 
browsed is that each CI read during a 
browse will always use the least recently 
referenced buffer in the pool. Browses 
spanning several data Cls will tend to fill 
the pool with those CIs being browsed 
since each CI will normally be read into 
a separate buffer. This can hurt the per- 
formance of other files sharing the pool 
by overlaying highly used data. For this 
reason, it is best to either not use LSR for 
files of this type or place them in a sep- 
arate pool by themselves. 

Control Area (CA) splits can cause per- 
formance problems in CICS, especially 
for files using LSR. When a CA is split, 
numerous I/O activities will occur, in- 
cluding reading and rewriting approxi- 
mately half of the CIs from one CA to 
another. On a typical KSDS with a 4K 
data CI size residing on a 3380-type de- 
vice, about 70 records will need to be 
read from the old CA and then copied to 
the new CA that will almost always be on 
another cylinder. With NSR, VSAM uses 
multiple buffers and attempts to read or 
write as much as a track at a time. This 
can significantly reduce the number of 
physical I/Os and the amount of DASD 
arm movement. With LSR, though, each 
record to be read and written requires a 
separate I/O operation. Since the two CAs 
are almost necessarily on separate cylin- 
ders, each I/O operation will involve 
DASD arm movement. Processing a CA 
split with LSR can take many times longer 
than with NSR. 
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During the time that VSAM is pro- 
cessing a CA split, the MVS TCB re- 
questing the split is suspended. In other 
words, while a CA split is occurring, no 
other work gets done in that CICS region 
unless VSAM subtasking is being used. 
If VSAM subtasking is being used, the 
subtask would be suspended limiting ac- 
cess to all VSAM files in that region. 
While CA splits are always troublesome, 
they are much more so with LSR. As a 
general rule, files should be designed to 
eliminate CA splits if at all possible. If 
CA splits cannot be almost totally avoided, 
it might be best to exclude the file from 
LSR processing. 

VSAM files defined with share-options 
of ‘*4’’ should not be used in LSR. (In 
fact, they probably should not be used in 
CICS.) Share-options **4’” is used in a 
crude sort of way to allow sharing of 
VSAM files. It requests that VSAM reac- 
cess each level of index and data from 
DASD each time data is retrieved. When 
share-options *‘4’” is specified, neither 
look-aside nor read-ahead processing will 
be done. There is no reason to have such 
files in LSR since Cls in buffers can nei- 
ther be reused nor benefit from look-aside. 


Tuning LSR Processing 


Usually when LSR is first used, several 
VSAM files are placed in a pool and 
everything runs fine. In most cases, there 
are several improvements compared to 
NSR. For one thing, there is usually a 
considerable decrease in the amount of 
virtual storage needed for the pool (which 
is not that important any more in an MVS/ 
XA environment since the pool can reside 
above the 16MB line), a slight reduction 
in working set size, a reduction in the 
number of physical I/Os and often a re- 
duction in total CPU utilization (espe- 
cially for DFP Releases 2.3 and later). 
Typically, the improvements of LSR over 
NSR have been significant enough that 
little concern is given to making it per- 
form even better. There are a few tech- 
niques, though, that can improve LSR 
performance and/or help balance resource 
utilization. 

The data and index CI sizes of VSAM 
files are quite important when using LSR. 
To begin with, data CI sizes should be 
different from index CI sizes for all files 
sharing a pool. Since LSR pools are sub- 
divided into subpools based on buffer size, 
having different sizes for data and index 
Cls will force them into different sub- 
pools. This will prevent data Cls (that 
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commonly have poorer read/hit ratios) 
from stealing buffers holding index CIs 
(that usually have good read/hit ratios). 
This need is particularly important when 
one or more files in the pool is more ac- 
tive than other files or when much browse 
activity is occurring. 

Since there is almost always a better 
read/hit ratio for index Cls than for data 
CIs, when data Cls are allowed to steal 
index buffers additional physical I/O ac- 
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tivity will occur. If at all possible, it is 
good to protect index CIs by isolating them 
from data Cls. It only takes one highly 
active data file stealing index buffers to 
lower the performance of the entire pool. 

There is also value in matching data 
and index CI sizes with allowable LSR 
buffer sizes. The only buffer sizes sup- 
ported by LSR are 512, 1,024, 2,048, 
4,096 and multiples of 4,096 up to 32,768. 
Cls of other sizes will use the next larger 
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buffer size. While some other CI sizes 
may have other storage/access advantages 
on certain media types, they will waste 
buffer space in LSR. 

Since any CI resident in memory will 
use an entire buffer, it might as well be 
filled with data to improve the chances 
that data will be in the pool when it is 
needed. Unless there are strong reasons 
to do otherwise, data and index CI sizes 
should be used that match LSR pool buffer 
sizes. 

On 3380 geometry, 4,096 is generally 
considered an ideal data CI size for most 
randomly retrieved VSAM files. This size 
provides a good balance of service and 
space utilization on the device. Prior to 
DPF Release 2.2, when VSAM could use 
only physical block sizes of 512, 1,024, 
2,048 and 4,096, it was considered good 
practice to choose data CI sizes when de- 
fining a VSAM file and allow VSAM to 
select an appropriate index CI size. At 
that time, VSAM was just about forced 
into assigning index CI sizes of 2,048 or 
4,096 for most VSAM files defined on 
3380-type devices. DFP Release 2.2 
changed the structure of VSAM by allow- 
ing physical records to be the same size 
as CIs. This change allowed more flexi- 
bility in VSAM record geometry but sig- 
nificantly increased exposure to another 
problem. 

When a data CI size of 4,096 is re- 
quested with DPF Release 2.2 and be- 
yond and index CI size is not also spec- 
ified when the file is defined, VSAM will 
be free to choose smaller index CI sizes. 
An index CI size of 1,536 is frequently 
chosen by VSAM. Using information 
about the file, the type of DASD upon 
which it was being created and the length 
of the key, VSAM will select the smallest 
appropriate index CI size based upon 
standard key compression algorithms. 
(VSAM compresses the keys stored in in- 
dex records to conserve space.) 

Unfortunately, when key compression 
does not occur according to standard pat- 
terns, the index CI size is sometimes not 
large enough to map all of the data Cls it 
controls. This leads to unusable space 
within the file and to premature CA splits. 
When VSAM was forced to use a 2,048 
index CI size instead of 1,536, the addi- 
tional space in the CI took care of most 
unusual key compression patterns. 

A data CI size of 4K and index CI size 
of 2K are preferred for randomly accessed 
VSAM files on 3380-type devices, espe- 
cially when used with LSR. This will pro- 
vide good DASD service, make good use 
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of space in the LSR pool, keep the index 
and data CIs in separate subpools and, in 
most cases, allow full utilization of space 
allocated to the file. In cases in which a 
2K index CI is not sufficient either be- 
cause of larger keys or poor key compres- 
sion, you can either increase the data Cl 
size to 6K or 8K or you can increase the 
index CI size to 4K. (If the index CI size 
cannot be 2K, it might as well be 4K since 
it will use a 4K buffer anyway.) 

It might be wise to avoid allowing both 
the index and data CI sizes to be 4K since 
there would be no way to place them in 
separate subpools. Unless the device or 
its path is overly busy, it probably would 
be better to increase the data CI size to 
6K or 8K and allow the index CI size to 
remain at 2K. A 6K data CI size would 
be better than an 8K CI size if DASD 
space is important (with 6K, you can get 
42K of data per 3380 track versus 40K 
with an 8K CI size). An 8K data CI size 
would be used to avoid wasted space in 
the LSR pool, especially if the DASD de- 
vice was not overly busy and/or was sup- 
ported by DLSE. 

Another way to improve LSR perform- 
ance is to use multiple LSR pools. Be- 
ginning with CICS Release 1.7 on MVS/ 
XA systems, CICS allows the creation of 
up to eight separate LSR pools. The 
placement of files into separate pools can 
improve the read/hit ratio for files in each 
of the pools. 

One of the most important things to 
consider when planning LSR pools is data 
and index CI sizes. As just mentioned, it 
is important to ensure that no file in a pool 
has the same data CI size as any other 
file’s index CI size. It is also worthwhile 
to separate files with good read/hit ratios 
from ones with poor read/hit ratios. While 
this will probably not help the files with 
poor hit ratios, it will prevent them from 
robbing buffers that are likely to be needed 
again quickly. 

Highly active files may warrant special 
planning. Files with high levels of activ- 
ity and good data read/hit ratios are prob- 
ably good candidates for having their own 
LSR pool, especially if their performance 
is critical. With only eight LSR pools and 
perhaps hundreds of files, it is usually not 
practical to give files their own pools, re- 
gardless of how active they are. When we 
cannot give this type of file its own pool, 
it may be possible to place its data Cls in 
a separate subpool. This can be done by 
using an unusual data CI size (such as 
12K) that is not being used by any other 
file in the pool. This might be especially 


beneficial for small files with high data 
read/hit ratios. 

However, care should be taken when 
larger data CI sizes are used. They can 
have a negative impact on the I/O sub- 
system. If the use of a separate subpool 
eliminates most of the read I/Os associ- 
ated with a file, the larger data CI size 
will probably have little impact unless 
there is also a considerable amount of 
write activity. Unless the volume upon 
which the file resides and the associated 
paths are all 30 percent or less busy (higher 
path activity can be allowed on DLSE ar- 
chitecture) and there is a significant im- 
provement in the read/hit ratio, larger Cl 
sizes should be avoided. If the separate 
subpool does not materially improve the 
read/hit ratio, it is probably better to con- 
tinue to use a smaller data CI size. 

Files with high levels of activity and 
poor data read/hit ratios should probably 
share a pool by themselves. Even if look- 
aside will do little for the data CIs, with 
an appropriately sized index subpool, a 
reasonably good read/hit ratio can still be 
achieved for index and sequence set Cls. 
For these files it is especially important 
that data and index CI sizes be different. 

Files involved with extensive browse 
activity may occasionally be good LSR 
candidates, but they should usually be 
placed in a separate pool or subpool. If 
the length of a typical browse request in- 
volves only one or two CIs, VSAM pro- 
cessing may not be materially different 
than for randomly accessed files (from an 
LSR perspective). The advantage of leay- 
ing such files under NSR is that one ap- 
plication (and only one!) at a time could 
benefit from VSAM’s read-ahead feature. 

The advantage of using LSR is that 
some CIs might already be in buffers. De- 
pending upon the particular read/hit ratio, 
there might be significant real I/O say- 
ings, especially for files experiencing 
shorter browse requests. 

Prior to DFP Release 2.3 (and on all 
non-XA releases), LSR may have used 
more CPU resource than NSR. At that 
time, LSR look-aside routines would scan 
every buffer in a subpool before ever as- 
signing a buffer for an I/O operation. If 
the correct CI was in the subpool, look- 
aside would scan an average of half of the 
buffers in the subpool before finding the 
correct one. If the CI was not in the pool, 
the entire pool would be scanned. Of 
course, if the CI was in the pool, the en- 
tire path length for scheduling and servic- 
ing an I/O would be eliminated. Larger 
pools required more CPU (one reason why 
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smaller pools used to be recommended). 
Higher read/hit ratios saved more of the 
CPU associated with scheduling I/Os. 
Depending on the size of the LSR pool 
and the read/hit ratio realized, LSR could 
have used more or less CPU than com- 
parable NSR file processing. 

DFP 2.3 introduced a new LSR buffer 
management technique called VSAM hash 
buffer management. This changed the way 
look-aside accessed buffers in a subpool. 
With this technique, VSAM look-aside 
routines use a hashing algorithm to cal- 
culate the address of buffers in the pool 
instead of searching through the pool se- 
quentially. The amount of processing re- 
quired to locate a record is now substan- 
tially less regardless of the size of the pool. 

With DFP 2.3, it is no longer necessary 
to create separate LSR pools to reduce 
CPU utilization. In fact, the opposite is 
true — the trend is now to make LSR 
pools as large as possible (within limits 
of storage) to improve the read/hit ratio 
for the pool. Larger pools can improve 
the read/hit ratio and reduce the number 
of physical I/Os requested for files in the 
pool. It can also reduce the CPU overhead 
needed to schedule and service the asso- 
ciated I/O events. Systems not troubled 
with paging problems or real storage con- 
straints can now reduce CPU usage by 
selectively increasing the sizes of various 
LSR subpools to improve read/hit ratios. 

Determining the optimal size of each 
LSR subpool requires consideration of a 
number of factors. The primary reason for 
increasing the size of an LSR subpool is 
to improve its read/hit ratio. The relation- 
ship between the number of buffers in a 
subpool and the resultant read/hit ratio is 
somewhat ‘‘exponential’’ in nature. That 
means that the read/hit ratio will improve 
rapidly at first but improve less rapidly as 
more buffers are added. 

The higher the read/hit ratio for a par- 
ticular subpool, the more buffers that must 
be added to improve the ratio. In other 
words, it will usually take more buffers 
to increase the read/hit ratio for a subpool 
from 90 to 95 percent than it did to im- 
prove that same subpool from 70 to 75 
percent. 

Data access patterns are the major fac- 
tor influencing read/hit ratios. Files for 
which data is reaccessed quickly will show 
greater benefits from increases in pool 
sizes than files with more random access 
patterns. The number of buffers necessary 
to achieve a given read/hit ratio is related 
to the likelihood that records will be ac- 
cessed multiple times in a relatively short 
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period of time. In some situations sub- 
pools with 20 to 30 buffers will achieve 
excellent read/hit ratios (90 to 95 percent 
or more) while subpools of 200 to 300 
buffers may achieve less than 60 to 70 
percent. The differences are entirely re- 
lated to the access patterns of files sharing 
the subpool. 

Of course, it is assumed that tuning for 
CI size and pool selection has been done 
before adjustments are made to pool sizes. 
It may be hard to compensate for poor file 
design or CI size selection simply by pro- 
viding additional buffers. 

It should be reasonable to expect read/ 
hit ratios of 90 percent or more for sub- 
pools used exclusively for indexes. In- 
creasing the size of these subpools until 
a 90 to 95 percent read/hit ratio is ob- 
tained is usually the easiest way to im- 
prove overall performance. 

Since DFP 2.3, when LSR’s look-aside 
processing was improved, LSR has be- 
come one of the best methods of improv- 
ing performance and extending the life of 
CPU-constrained processors. On proces- 
sors with expanded storage, if read/hit ra- 
tios can be materially improved by cre- 
ating large subpools, total CPU utilization 


will usually be lower, even if additional 
paging results. As long as the page faults 
generated by an increased working set size 
can be satisfied from expanded storage, 
the CPU savings associated with im- 
proved read/hit ratios should be greater 
than the CPU usage associated with sat- 
isfying page faults. While larger LSR 
pools will increase working set size and 
paging rate, the net result can still be a 
reduction of total CPU usage along with 
performance improvements resulting from 
replacing real I/Os with satisfied look- 
aside requests. 

When we discuss expanding the life of 
a CPU-constrained processor, we nor- 
mally talk about two primary aspects: the 
reduction of total CPU utilization and the 
ability to achieve acceptable service lev- 
els at higher levels of CPU utilization. By 
exploiting LSR and expanded storage, we 
can do both. Much larger buffer pools will 
probably become common as we attempt 
to make better use of processor resources. 


Measuring LSR Effectiveness 


Standard CICS statistics produced at 
shutdown give a picture of how the pool 
performed overall. The statistic, “‘Num- 
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ber of successful look-asides,’ is the 
number of requests satisfied directly from 
the subpool. The statistic, ‘‘Number of 
buffer reads,’’ indicates the total number 
of records actually retrieved from the I/O 
subsystem. The read/hit ratio can be de- 
termined by dividing the total number of 
requests satisfied from the pool by the to- 
tal of that number and the total number 
of read I/O requests. This statistic gives 
a picture of how well the pool performed 
for the entire time CICS was processing. 
If more precise information is needed for 
a specific period of time, these same sta- 
tistics can be produced in separate inter- 
val reports. 

Information on read/hit ratios for spe- 
cific files is not available directly from 
CICS but is available using various CICS 
performance monitors. One vendor's 
monitor provides some satistics that are 
particularly useful. It indicates the total 
logical I/O services requested for each file 
(that is, read, write, add, delete and 
browse requests) and the number of 
EXCPs actually scheduled. For LSR files, 
these numbers are a good indication of 
the read/hit ratios for a file unless there 
is a lot of browse activity against the file. 
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Some monitors analyze LSR pool per- 
formance without identifying specific files. 

Service times may also be shown either 
by file or by subpool. While low service 
times usually reflect good read/hit ratios, 
they can be influenced by a number of 
factors such as the amount of browse ac- 
tivity, the type of DASD and whether the 
DASD is being cached. Service times are 
clearly the ‘‘bottom line.’’ Most I/O tun- 
ing is done to improve the average delay 
in providing data to applications. 


Other Considerations 


When VSAM _ Subtasking (VSP) is 
being used, CICS sets up a separate MVS 
task to service VSAM I/O requests. This 
allows most of the processing associated 
with VSAM I/O requests to be processed 
under a separate TCB. In multi-processor 
complexes (dyadic, quadratic and so on), 
VSP is used primarily to relieve CPU- 
constraint in overly busy CICS regions. 
When VSP is used, all VSAM I/O re- 
quests will be serviced by the VSAM sub- 
task removing some processing burden 
from the main CICS TCB. Since VSP adds 
a considerable amount of overhead, it is 
not normally used unless a CICS region 
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has a CPU demand of 80 percent or more. 
(CPU demand is defined as the sum of the 
time a CICS region is using the CPU plus 
all other time it is attempting to use the 
CPU but cannot, such as when it is wait- 
ing for page faults or CA splits or for the 
availability of a processor being used by 
other higher priority MVS tasks.) Of 
course, VSAM subtasking is not recom- 
mended for use on a uniprocessor. 

The use of VSP in a heavily LSR-ori- 
ented environment may be somewhat 
counterproductive. When VSAM files 
have high read/hit ratios, read accesses 
will be serviced quickly without sched- 
uling much I/O and associated processor 
utilization will be minimal. Without VSP, 
service can be almost immediate. With 
VSP, requests must be shipped to the sub- 
task for processing. This can add unnec- 
essary delays and overhead in VSAM 
processing. 

When LSR is used extensively, the need 
for cache controllers can be reduced con- 
siderably. Generally speaking, files with 
reasonable LSR read/hit ratios become 
poor cache candidates. The only I/O re- 
quests fowarded to the I/O subsystem are 
the ones that failed look-aside. Since LSR 
provides a type of pre-cache, the read/hit 
ratio within the cache controller will often 
not be high enough to justify the use of 
cache. 


Conclusions 


In most CICS environments, LSR 
should be the vehicle of choice for ac- 
cessing VSAM KSDS files. While there 
are a few restrictions on its use, it will 
normally provide the best service and 
make the best use of available resources. 
With the enhancements to the look-aside 
feature provided in DFP Release 2.3, LSR 
has become a powerful tool that may be 
used to meet both performance and ca- 
pacity objectives. = 
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a chance and hope you'll be able to 
find changes before they damage your 
system. Or you can install DELTAMON 
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MVS can protect the health of your 
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Still Makes 


hese frequently used adages are be- 
coming more and more uncritically 
accepted by data processing man- 
agement. ‘‘Computers are now so fast that 
it does not matter how inefficient your 
program is’’. . . ‘Concentrate on the ap- 
plication, not the program’’. . . ‘‘Spend 
your time on a structured program, not a 
technically efficient program.’’ The say- 
ing used to be, “‘It is important to write 
efficient code.’” Why has this idea fallen 
out of favor in recent years? 

It is indisputable that efficient code is 
at least sometimes necessary. As compa- 
nies grow, so does the amount of data 
they process. When the rate of increase 
of data processed exceeds the rate of in- 
crease in the speed of computers, addi- 
tional processing time becomes critical. 
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If a production run cannot finish between 
the time a company ends daily processing 
in the evening and begins the next day’s 
activities, a company cannot function. 
Furthermore, even if a job can process in 
this time frame, any programming prob- 
lems become major ones. The schedule 
may be too tight to allow for a rerun. 
Efficiency can actually be the deciding 
factor between life and death. I have a 
friend that has written programs designed 
to automatically perform defensive ma- 
neuvers of the F16 fighter jet. Imagine a 
missile coming at your jet and your sud- 
den realization that your program is run- 
ning slowly due to inefficient code. You 
had better hope that you can get your par- 
achute and bail out more efficiently than 
your defensive program was processing. 


Cnse 


Efficient programs certainly save a 
company money. At the end of 1984, I 
spent more than a month updating COBOL 
programs that ran on an IBM 3081. By 
using techniques detailed in this article, I 
was able to save between 15 and 95 per- 
cent of the CPU time for each program. 
This saved a major insurance company 
more than $30,000 each time the pro- 
grams were executed which was a few 
times per year. One program that origi- 
nally ran in more than three hours CPU 
time was changed to run in less than one 
hour while another was changed from 
running more than 15 minutes to less than 
one minute. 

Efficiency is unfortunately considered 
something that when added to a program 
makes the program more convoluted and 
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harder to maintain. While this is the case 
in some highly technical pieces of code 
that strain the limits of COBOL, this code 
is rarely added for efficiency alone. It is 
a fallacy that efficient code must be dif- 
ficult code. One often overlooked valu- 
able result of efficient code is that the pro- 
gramming logic is often easier to follow. 
Consider the example that locates a month 
name based upon the numeric value of the 
month (see Figure 1). Which of the code 
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segments do you find easier to read and 
understand? 

It is quite apparent that efficiency is not 
always of primary importance. If a pro- 
grammer writes code that will run only 
once, a small program that runs quickly 
or a large program that processes a small 
amount of data, extra time spent in mak- 
ing the program run faster is not cost- 
effective. Yet, with a proper understand- 
ing of the concepts of COBOL efficiency, 
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the basics of which can be learned in about 
two days, you can learn to write efficient 
code as quickly as you can write ineffi- 
cient code. Although it may be hard to 
break bad habits, it is much easier than 
you think to code efficiently. 

Figure 2 illustrates two different pieces 
of code that serve the same function. Al- 
though the code segments look quite sim- 
ilar and would take approximately the 
same amount of time to write, one of the 
segments runs about three times as fast as 
the other. Reading this article should make 
it quite apparent as to which is the faster 
running code. 

It often pays to scrutinize existing code 
and improve its speed. A COBOL pro- 
gram of 1,500 lines that has already been 
written can be reviewed and updated to 
run faster in less than a day. I have rarely, 
if ever, seen a program that cannot be 
made to run at least 15 percent faster. One 
quick approach is to install a program 
monitor and determine the exact points in 
your system where excess CPU time is 
being utilized. These are the points at 
which you can concentrate your effi- 
ciency efforts. 

Perhaps you are convinced that the ef- 
ficiency of a COBOL program is impor- 
tant but it can be accomplished by one of 
the fine COBOL optimizer programs on 
the market. An optimizer can only make 
the best out of the code it is given. It 
cannot rewrite the logic. While it may in- 
crease the speed of a poorly written pro- 
gram, this is no substitute for well-written 
code that is optimized. 

Following is a description of a number 
of techniques to enable an IBM main- 
frame COBOL program to run faster. 
While the list does not specify all meth- 
ods, it serves as a starting point from 
which to proceed. The coding suggestions 
serve to motivate you into examining new 
techniques of your own. By using the 
COBOL Procedure Map (PMAP) that 
contains the Assembler language listing 
of a program, you can extend your ability 
through the study of the Assembler code 
produced for different methods of COBOL 
coding. You can also experiment by run- 
ning two different programs that produce 
the same results and by comparing the 
speed of each. 


Arithmetic Efficiencies 


The IBM 370 family of mainframe 
computers performs fixed point arithmetic 
using one of two formats: packed decimal 
or binary. Packed decimal fields are rep- 
resented as COMP-3 and binary fields as 
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COMP in COBOL programs. While 
packed decimal arithmetic may be done 
in memory, binary arithmetic always re- 
quires at least one register. This means 
that it will often take more instructions 
to do computations on a binary field 
than on a packed decimal field. However 
binary instructions are faster and usually 
more than make up for the additional in- 
structions. 

Zoned decimal fields are defined in 
COBOL as display numeric: a numeric 
field with neither COMP-3 nor COMP as- 
sociated with it. If arithmetic calculations 
must be performed on the field, the hard- 
ware requires that the field be converted 
to either packed decimal or binary, thus 
increasing the amount of time necessary 
for the code to execute. 

Arithmetic calculations should be made 
between fields of a similar type whenever 
possible, packed decimal to packed dec- 
imal or binary to binary. Whenever a cal- 
culation is made between a packed deci- 
mal and a binary field, the compiler will 
be forced to convert one of the fields (that 
can be to either packed decimal or binary 
depending upon the exact circumstances), 
thus using extra computer time. 
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An often overlooked efficiency is that 
calculations should be performed upon 
fields that have the same number of dec- 
imal places. It is not important whether 
one field is longer than the other, only that 
the number of places on the right side of 
the decimal point be the same. When this 
is not the case, the compiler has to create 
code to move one of the fields into a work 
area where it will be given the same 
amount of decimal places as the other 
field. This may also cause an additional 
move if the work area field must then be 
moved into the resulting field. 

It should be understood when calcula- 
tions are to be performed upon fields of 
different descriptions or differing number 
of decimal places, one of the fields can 
be moved to a WORKING-STORAGE 
field that matches the description of the 
other field. This technique will improve 
the speed of the program if the field is 
used multiple times. However it is not 
useful when a field will be used only once 
since the COBOL compiler will make the 
conversion just as efficiently as an added 
MOVE statement. 

An understanding of packed decimal 
and binary arithmetic on the IBM 370 
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leads one to analyze the lengths that are 
best for each type of data as well as 
whether signs should be used on fields. 
Packed decimal fields allow two digits for 
each byte except the last that contains one 
digit and a sign. Therefore, a packed dec- 
imal field must always contain an odd 
number of digits. If a packed field is de- 
fined to the COBOL compiler as having 
an even number of digits, the compiler 
must generate extra code to strip out one 
of the digits. 

Binary fields are handled as either half- 
words (that can hold any four-digit num- 
ber) or fullwords (that can hold any nine- 
digit number). Any larger field must be 
manipulated by the compiler to produce 
proper results, even though the hardware 
does not specifically support an instruc- 
tion for this function. Binary fields with 
more than nine digits should be used with 
caution. Although some large binary 
numbers can be handled effectively by the 
compiler, many times the fields are inter- 
nally converted to packed decimal. While 
COBOL allows only 18 digits for a nu- 
meric field, the hardware allows 31 for a 
packed decimal field. 

Beware of using large numeric fields 
regardless of their internal representation. 
For instance, if a division is done using 
two eighteen-digit fields with differing 
numbers of decimal places, a COBOL in- 
ternal subroutine will be called to do a 
division similar to the long-hand way it 
is done on paper. The division may take 
as long as the rest of the program. 

Arithmetic should also be done be- 
tween fields that are defined with a sign: 
an S in the data definition. COBOL does 
all arithmetic as signed whether or not it 
is requested as such. When a field is not 
defined as signed, the compiler must in- 
sert an extra instruction to remove the sign. 


IF Statements 


Many programmers fail to code the IF 
statement efficiently. It requires a certain 
amount of understanding and finesse to 
code eloquently. Take for example the 
code in Figure 3. The second segment of 
code is an attempt to be faster, yet accom- 
plish the same function as the first seg- 
ment. If CHECK-FIELD is always nu- 
meric, the second version will run much 
faster and is fine. However if CHECK- 
FIELD is not always numeric, while the 
second segment looks equivalent to the 
first, it may produce different results! A 
value of 2X will not make the first IF 
statement true but will make the second 
true. 
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Alphanumeric rather than numeric 
compares should be used whenever pos- 
sible, since they are faster. They also will 
not cause abends when invalid data ap- 
pears in a field. Note that signed display 
numeric fields are the least efficient fields 
to compare. The compiler must first con- 
vert the fields to packed decimal so that 
a numeric compare can be done. 

One valuable piece of knowledge of 370 
hardware is the fact that immediate in- 
structions exist where the operand field of 
a single character is placed into the in- 
struction itself rather than into data stor- 
age. This enables an IF or MOVE state- 
ment operating on a single constant 
character to run about three times as fast 
when the field is coded as a constant in 
the statement rather than have the field 
defined as a constant in WORKING- 
STORAGE. Defining frequently checked 
indicators as one-byte fields with values 
of Y and N instead of YES and NO should 
not detract from the clearness of a pro- 
gram while increasing its speed. 

It should be mentioned that using an 88 
level field in an IF statement is neither 
more nor less efficient than comparing a 
field to a constant. In either IF statement 
in Figure 3, code of equivalent speed 
would have been generated had the pro- 
gram used the 88 level rather than the 
constant values. In the first case, six com- 
parisons must be done while in the sec- 
ond, only two. 

Complex IF statements that contain a 
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number of AND and OR conditions can 
be speeded up simply by rearranging the 
order of the condition checks. The rule 
for efficient comparisons is as follows: in 
statements with many OR conditions, put 
the conditions with the greatest chance of 
truth first; in statements with many AND 
conditions, put the conditions with the 
greatest chance of truth last. The rule can 
be applied to nested IF statements as if 


en 


DATA DIVISION. 
WORKING-STORAGE SECTION. 
01 CHECK-FIELD 

88 CHECK-VALUES 
PROCEDURE DIVISION. 


PIC XX. 
VALUE ‘01’ ‘02’ ‘03’ ‘04’ ‘05’ ‘06’. 


IF CHECK-FIELD = ‘01’ OR ‘02’ OR ‘03’ OR 


‘04’ OR ‘05’ OR ‘06’ 


DISPLAY ‘***IS EQUAL***’. 


DATA DIVISION. 
WORKING-STORAGE SECTION. 
01 CHECK-FIELD 

88 CHECK-VALUES 
PROCEDURE DIVISION 


PIC XX. 
VALUE ‘01’ THRU ‘06’. 


IF CHECK-FIELD > ‘00’ AND < ‘07’ 
DISPLAY ‘***IS EQUAL**”’, 
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PIC 99. 
PIC XXX. 


PIC XX. 
PIC X. 


nbd 


they were multiple AND conditions. If 
you give the rule a bit of thought, it will 
become clear why it is true. 


Table Handling 


Optimizer programs can do a great deal 
to improve the performance of table han- 
dling in COBOL programs. Yet there are 
a number of technical points to consider 
to increase program speed when process- 
ing tables whether or not your program 
will be optimized. Most COBOL pro- 
grammers can recite that it is better to use 
an index than a subscript mainly because 
it is a common interview question. What 
most programmers do not realize is that 
not only are absolute subscripts (sub- 
scripts defined as a constant in the state- 
ment using it) the most efficient form of 
subscripting; but also, they are more ef- 
ficient than indexes and no less efficient 
than using a field that is not in a table! 
This is because when an absolute sub- 
script is used, the compiler makes the ex- 
act determination of where the field is. At 
run time, the object code does not have 
to perform calculations to locate the field 
in the table. 

While indexes are more efficient than 
subscripts, many, if not most program- 
mers, do not use indexes often. Perhaps 
it is because they do not have the ambi- 
tion to learn how to use them properly 
and how to find them in a dump. 

If a subscript is used, it is always in- 
ternally used as a binary integer. This is 
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the reason that subscripts should be de- 
fined as COMP whenever possible. 


PERFORMs and GO TOs 


When I teach that PERFORMs are in- 
efficient and should be avoided where 
program speed is a major concern, it never 
fails to amaze me when at least one per- 
son jumps up and complains that I am 
attempting to destroy structured program- 
ming concepts. One would think that I 
was a KGB agent who had infiltrated the 
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COBOL Efficiency 


United States to destroy programming 
through my teachings. 

Take a look at Figure 4. It is not hard 
to tell which segment of code is easier to 
read as well as many times faster. Unless 
a PERFORM is in-line, as can be done in 
COBOL II, you have to find the per- 
formed paragraph making it harder to 
follow the code. Since PERFORM state- 
ments may be harder to follow than in- 
line code, why not avoid them when pos- 
sible? This becomes of added value when 
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the code is performed millions of times 
and the added overhead of a PERFORM 
is eliminated. 

One rarely used but extremely efficient 
statement in COBOL is GO TO DE- 
PENDING ON. Regardless of how many 
possible paragraphs are the object of the 
GO TO clause, the code never takes more 
than 10 or 11 instructions to branch to the 
correct paragraph. This is because 
COBOL does not generate a list of IF 
statements but utilizes a branch table that 
uses the DEPENDING ON value as its 
subscript. When analyzed there are often 
cases that can use the GO TO DEPEND- 
ING ON statement, such as a program 
that peforms 50 different routines de- 
pending upon a numeric state code. 


File Processing 


Fixed-length records should be used 
rather than variable-length records when- 
ever possible. Avoid using the OCCURS 
DEPENDING ON clause to define vari- 
able-length COBOL data items whether 
they are record descriptions or WORK- 
ING-STORAGE fields. Every time the 
object field of the OCCURS DEPEND- 
ING ON changes, COBOL takes time to 
recompute the length of the data item. 

When variable-length records with a 
wide range of lengths are used, one ex- 
tremely efficient technique is to use the 
APPLY WRITE-ONLY clause in the I-O- 
CONTROL paragraph. While it may come 
as a surprise to many, COBOL often does 
not fill up a variable-length block before 
writing it. As an example, take a program 
that uses a file containing two record sizes: 
100 bytes and 10,000 bytes. Assume that 
the block size of the file is 10,008. While 
it may seem that many 100-byte records 
will be placed into a block before it is 
written, this is normally not the case. 

After COBOL puts a variable-length 
record into a block, it checks whether the 
largest record that may be written by the 
program can fit into the current partially- 
filled block. If it cannot, the current block 
is written out. In our example, if a 100- 
byte record is written into an empty block 
by a program, COBOL checks whether a 
10,000-byte record will fit into the par- 
tially filled block. It cannot, so the block 
is written. If the program continually 
writes 100-byte records, each will be 
placed into its own block! 

I/O takes a considerable amount of 
computer time and when records are not 
blocked, the processing time can increase 
significantly. To prevent this occurrence, 
the APPLY WRITE-ONLY clause in- 
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structs the compiler to fill a variable-length 
block to its maximum capacity waiting 
until the record length of a WRITE state- 
ment is known rather than predicting DATA DIVISION. 

whether the next record might not fit into WORKING-STORAGE SECTION. 
the current block. While some coding re- 01 TABLE-SUB 

strictions must be followed when the 01 TABLE-OF-VALUES. 

clause is coded, it is well worth using. 05 TABLE-ENTRY OCCURS 3 TIMES PIC S9(3) COMP-3. 
PROCEDURE DIVISION. 


PIC S9(4) COMP. 


Compiler Options 


CLEAR-TABLE. 
PERFORM CLEAR-ENTRIES THRU CLEAR-ENTRIES-END 
VARYING TABLE-SUB FROM +1 BY +1 
UNTIL TABLE-SUB IS GREATER THAN +3. 


What if someone told you that they 
might be able to make your COBOL pro- 
gram run faster without changing a line 
of code? Although it sounds like a trick, 
it is fact that programs will run faster or 
slower depending upon the compiler op- 
tions chosen. This has nothing to do with 
a compile taking four or five times as long 
because one uses options like PMAP and 
SXREF on the first compile rather than 
SYNTAX. 

The NOTRUNC option is rarely under- 
stood which is not surprising because of 
the way it is described in the IBM man- 
ual. It allows a program with COMP fields 
to run faster. Furthermore, depending upon 
how the program was coded, it may ac- 
tually be a necessary option for the pro- 
gram to run properly. As mentioned ear- 
lier in this article, binary fields require a 
halfword for COBOL fields defined up to 
four digits long and a fullword for fields 
up to nine digits long. A halfword really 


CLEAR-ENTRIES. 
MOVE ZERO TO TABLE-ENTRY (TABLE-SUB). 


CLEAR-ENTRIES-END. EXIT. 


DATA DIVISION 
WORKING-STORAGE SECTION. 
01 TABLE-OF-VALUES. 
05 TABLE-ENTRY OCCURS 3 TIMES PIC S9(3) COMP-3. 
PROCEDURE DIVISION. 


CLEAR-TABLE. 
MOVE ZERO TO TABLE-ENTRY (1). 
MOVE ZERO TO TABLE-ENTRY (2). 
MOVE ZERO TO TABLE-ENTRY (3). 


holds up to 32,767 while a fullword up 
to 2,147,483,648. While a halfword or 
fullword COMP field in COBOL is de- 
fined as having a limit of 9,999 or 
999,999,999 respectively, the actual 
numbers that may be put into the fields 
are larger. 

The TRUNC option assures that when 
arithmetic is performed on a COMP field, 
the result does not exceed the maximum 
value that the field is defined as, adding 
extra machine code to do so. It is rare 
that a program wishes to ensure that a 
field exceeding its defined number of dig- 
its be truncated to the defined size. A more 
common practice is for a COBOL pro- 
gram to require that a field not be trun- 
cated because it is holding an address, as 
is the case in CICS programs. I see no 
reason that every company not make the 
NOTRUNC option the default for all 
compiles. 

I would also like to mention a new op- 
tion that has been added to the COBOL 
II compiler and will become important as 
companies convert. The SSRANGE op- 
tion ensures that subscripts used in a pro- 
gram do not exceed the maximum entry 
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number of a table. While this option is 
long-awaited and will prevent storage ov- 
erlays as well as protection exceptions 
when programs are tested, the machine 
code added by the compiler will make the 
program run considerably slower. While 
useful in development of programs, the 
option should be avoided in the produc- 
tion environment. 

While it is in vogue to accept as normal 
an environment of programmers who do 
not understand the implications of their 
own code relying upon the wide array of 
debugging and optimization products, the 
programmer who lacks the detailed 
knowledge of COBOL will also be lack- 
ing in productivity. It should be realized 
that anyone who suggests that program- 
mers attempt to use a programming lan- 
guage without the understanding of those 
important intricacies of the language are 
asking the programmers to stumble around 
in the dark. The time spent by a program- 
mer to understand a language, rather than 
blindly code it, will end up as cost effi- 
cient since coding errors will be resolved 


considerably faster. Rather than compa- 
nies running to upgrade to faster ma- 
chines to run their programs, let them run 
to educate their programmers — their most 
valuable resource. This rearrangement of 
priorities will translate into dollars saved 
and more knowledgeable programmers 
ready to meet the new technical chal- 
lenges ahead. = 
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uery Management Facility (QMF) is IBM’s 

offering as an end-user report writing tool for 

DB2 data. It is marketed as a user-friendly 

product and, indeed, was proven to be so at 

the Electrochemical, Detergent and Specialty 
Products Group (ED&S) of Occidental Chemical 
Corporation. 

As a member of the newly created four-person 
information center within the information services 
department when I joined the company in May, 
1985, my mission 
was to provide mi- 
cro and mainframe 
user tools and sup- 
port to compliment 
the existing pro- 
duction systems. 

One of the major 
problems at that 
time was a backlog 
of requests for ad 
hoc reports; the av- 
erage turn-around 
time was slightly 
more than three 
weeks. It was ob- 
vious that the tools 
that were available 
to the user com- 
munity (SAS, In- 
quire IV _— and 
AnswerDB) did not 
provide the ease of By 
use that was re- y 
quired. 

Most of our po- 
tential users were from the sales, marketing and cus- 
tomer service areas, people with minimal technical 
skills. This fact, combined with our limited training 
and support staff, dictated that we find a truly user- 
friendly product. 

Most of the data required by users already resided 
on the mainframe and micro computers did not exist 
on a widespread basis; so our choices were limited to 
the mainframe environment. Most of the data was 
either in IMS databases or in flat files that further 
restricted possible product selections. This was a con- 
straint unique to our staff size and the timeframe within 
which we needed to provide some relief. Writing our 
own bridges from IMS to a new product was not a 
viable alternative. 
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DBZ 


Query Management 


Facility 


One User’s Experience 


Mary Jo Cater 


e reviewed most of the 4GL report-writing 
and database products on a preliminary level. 
An extensive comparison was made between 
IDMS/R and Cullinet’s report writing prod- 
ucts with IBM’s DB2, DXT and QMF. For 
our final test, we asked both vendors to load our sam- 
ple data on their machines. We then requested that 
they generate 12 specific reports while we watched. 

The results of these comparisons provided a clear 
decision for us: IBM’s DB2, DXT and QME. The 
direction of IBM 
toward support of 
DB2 as a produc- 
tion database heav- 
ily influenced our 
decision as did the 
availability of DXT 
for simple IMS data 
extraction. The key 
reason for our se- 
lection was the im- 
mediate __ benefits 
that QMF could 
provide. 

We selected sev- 
eral projects and 
users to be in- 
volved in a three- 
month pilot of the 
IBM products. We 
installed DB2, 
DXT and QME un- 
der TSO in early 
January, 1986. 
During the _ first 
months of the pi- 
lot, the scope was expanded and the time extended to 
six months. At the conclusion of the pilot, a formal 
recommendation was made to purchase DB2, QMF 
and DXT. Due to enthusiastic user response, this rec- 
ommendation was approved. 

Over the past several years, the amount of data that 
has been made available to QMEF users has increased 
dramatically. We currently have more than seventy 
tables/views and well over one hundred active users. 
New tables and users are constantly being added as 
quickly as we can accommodate them. 

This activity is impressive only when you consider 
our staff size and the fact that there is no longer any 
backlog of requests for ad hoc reports. The Informa- 
tion Center (that has expanded to seven members) has 
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DB2’s Query Management Facility 


only two people with QMF/DB2 respon- 
sibilities. I extract and load the data, de- 
sign and create the tables/views/indexes, 
monitor performance and train users. The 
other person spends almost 100 percent 
of his time writing complex ad hoc re- 
ports. The fact that we have been able to 
expand our user base without increasing 
support staff speaks highly for QMF. 

Occidental has recently begun appli- 
cation development in DB2 on a corpo- 
rate-wide basis and we expect to see con- 
tinued growth in that direction. A key 
factor in DB2’s selection for many of these 
initial projects has been the report writing 
capabilities of QMF. 

QME offers two languages (QBE and 
SQL), an extensive array of functionality 
in formatting reports and procs (proce- 
dures) that can run and print formatted 
reports in one step. 

Query by Example (QBE) is similar to 
an older IBM product with the same name 
that ran under VM. Users familiar with 
the old QBE product naturally like the 
QBE language. During our pilot, some of 
our users were attracted to the simplicity 
of QBE but quickly (within days) became 
convinced that it is too cumbersome to 
use. QMF actually takes the QBE query 
and converts it to SQL prior to execution, 
so there is some minor additional over- 
head involved. 

Structured Query Language (SQL) is 
actually a subset of the SQL language that 
is quickly becoming an industry standard. 
The syntax is quickly learned since it is 
fairly logical. (My advice is to read the 
query aloud; if it makes sense, it will 
probably run.) 


Excellent Help Function 


Part of the ease of use can be attributed 
to the excellent help function and error 
messages that are part of the QMF pack- 
age. When the error message reads, “‘SQL 
error at or before line three position 24,”’ 
the user has a pretty good idea why the 
query did not run. The help function will 
further explain why the error message oc- 
curred and offer some suggestions as to 
how to resolve the problem. 

A typical query in QMF might read: 
SELECT REGION,CUSTOMER, CUST_NAME, 

PRODUCT,SUM(NET_SALES) 

FROM TSALES 
WHERE DIVISION = ‘42’ AND DISTRIBUTOR = ‘N’ 
GROUP BY REGION,CUSTOMER,CUST_ 

NAME,PRODUCT 

ORDER BY 1,5 DESC 


This query selects the named columns, 
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adds together the net sales (so that for 
each region-customer-product, one row is 
returned) for those rows in a specified di- 
vision and a specified type of distributor. 
The results are ordered first by region (and 
then within region) and are ranked by 
sales. 

One key user-friendly feature is that 
spaces have no meaning. A query may be 
strung out on one line or spaced anywhere 
on the query screen. I suggest using a new 
line for each keyword as shown in the 
example. This makes the query easier for 
other people to read. 

I have also created ‘‘common librar- 
ies’’ of queries and forms that are avail- 
able to all users. This provides samples 
for users to modify and cuts down on 
learning time. Some of the queries in this 
library have been built with variables that 
prompt the user for specific restrictions at 
run time. 


Form Function 


Once a query has been run, the form 
function can be used to format the results. 
A default form is created by QMF that 
spaces the columns nicely across the page 
and uses the column names for headings. 
The user can change any of these defaults 
including omitting any column from the 
report, changing the number of decimal 
places reported, wrapping a column of 
data (like customer name and address), 
changing the column headings and chang- 
ing the field lengths. 

The form function allows up to five lines 
of title, five lines of footing and 14 lines 
of final text. The report can have up to 
six levels of breaks (a break separates the 
data for readability and subtotals) and 
provides the capability to add break text 
at the heading and footing. The form al- 
lows the user to obtain averages, per- 
centages, totals, minimum and maximum 
values. 

Both the query and form can be saved 
for later use. Simple commands allow the 
user to display a list of saved items, dis- 
play one of those items, erase old items 
and so on. 

Often the user is just looking for some 
information and may not even print the 
results of the query. If a printed report is 
desired, a PF key does the job. For two 
copies, you depress the function key 
twice. The print is directed to the printer 
defined in the user’s QMF profile or the 
default printer. We have most of our re- 
mote sites defined to GDDM (that QMF 
uses for printing), so that we can print 


any report in our key locations. 
Procedures 


To further simplify the query/form 
process, QMF provides for the creation 
of procs. A proc is merely a list of com- 
mands that can be executed in one step, 
either on-line or in batch. A very basic 
proc might look like this: 

RUN QREGIONI (FORM = FREGIONI 
PRINT REPORT 
PRINT REPORT 
RUN QREGION2 (FORM = FREGION2 
PRINT REPORT 

This proc runs the query QREGION1 
with the form FREGION| and prints two 
copies of the report. Then it runs the query 
QREGION2 with the form FREGION2 
and prints one copy of that report. 

Procs are especially useful in the batch 
environment. Batch can be run through a 
QMF panel, from TSO or scheduled as 
part of normal production. One nice fea- 
ture of using a QMF proc for batch re- 
porting is that the queries and forms can 
be changed to reflect user needs often 
without rewriting the procedure or chang- 
ing the JCL. 

During our pilot, users were exposed 
to very simple table joins (two tables with 
a customer number key, one with sales 
data and the other with customer name 
and address). The concept was poorly re- 
ceived, resulting in confusion and incor- 
rectly joined tables. To avoid this prob- 
lem, we make extensive use of views. Our 
users are not even authorized to see many 
of our base tables; they use views that join 
several tables and often restrict what data 
the user will see. If someone has a need 
to join other tables, I build them a view 
on an ad hoc basis. 

QMF also provides the syntax to 
UNION tables with similar fields. We have 
two tables that are good candidates for 
union: Open Orders and Billed Orders. 
Like joins, users have difficulty with this 
concept and the creation of a view has 
solved this problem. 

Security 

Security is handled for the most part by 
DB2. Access into QMF can be either open 
or closed. I suggest using closed to main- 
tain control over those who would like to 
““play around’’ with the product. Once a 
user is authorized into QMF, the DB2 au- 
thorization for each table or view controls 
access to specific data. DB2 provides for 
virtually any level of security that is re- 

See DB2 page 77 
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ES/9370 


By Stephen H. Quanrud 


| 2 
Sd 


aa 
Dr. Teter of Corning Glass Works with a glass crystal. The screen in the background is a 
computer model of 288 atoms of silica, or glass. 


apping at a keyboard, the re- 

| searcher inputs commands telling 

the computer to translate huge 

numbers of instructions into graphic 

forms. Moments later, images of blue and 

yellow appear on the researcher’s com- 
puter terminal. 

As the screen fills, a pattern emerges: 
marble-sized spheres connected by rods, 
complete with shading. It looks vaguely 
reminiscent of high school chemistry. . . 
perhaps the pattern represents a mole- 
cule? Actually, it is less than that. It is 
one slice of one molecule. 

This is a demonstration at the research 
and development complex at Corning 
Glass Works where a scientist is simulat- 
ing a unique view of chemicals at work. 
Though it represents a tiny piece of mat- 
ter, the model on the computer terminal 
carries big potential for the glassmaking 
firm. Generated by an IBM Enterprise 
System/9370, the graphics represent a 
precise view of how 288 atoms of molten 
glass might appear when cooled. 

“‘When atoms are hot and moving 
around, they’re not that important to us,”’ 
says Michael Teter, Ph.D., Corning’s en- 
gineering fellow. ‘‘We need to know what 
happens when they cool and settle down. 
Computer simulation gives us a still pho- 
tograph of that phenomena very quickly 
without having to go through weeks or 
months of work.’’ 

To most engineers, computer simula- 
tions are becoming commonplace. Super- 
computers routinely simulate phenomena 
ranging from the chemical reaction among 
atoms to the interaction of cold and warm 
fronts in weather. However, what is unique 
with the Corning computer model is the 
hardware used: this one was generated not 
by a supercomputer, but by one of the 
smallest of IBM mainframes, the ES/ 
9370, in partnership with the IBM 3090 
supercomputer at Cornell University’s 
theory center. 

“Using an elaborate, exact supercom- 
puter program, we figure out what the in- 
teractions are between the atoms. Then 
we make up forces that approximate that 
for a simplified model and that’s the one 
we do on the 9370,” explains Dr. Teter, 
who personally wrote the modeling soft- 
ware used for Corning’s ES/9370. 

According to Dr. Teter, perhaps the 
biggest benefit of the 9370/3090 combi- 
nation is at the heart of simulation itself: 
quick visualization of physical problems 
under investigation. 

“You could look at 100 pages of num- 
bers,’’ he points out, referring to the com- 
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puter instructions required to generate the 
graphics on the screen. **But drawings like 
this help us visualize what the numbers 
mean by letting the computer figure out 
exactly what a simulated effect looks 
like.” 

For Corning Glass Works, the potential 
for improved product quality or even new 
products offered through computer mod- 
eling is tremendous. With 60,000 prod- 
ucts, 47,000 corporate clients, millions of 
customers and $2 billion in annual sales, 
Corning (like other companies including 
IBM) is continually looking for ways to 


Corning gains 
cutting edge 
in glass 
modeling. 


quickly and effectively improve its prod- 
ucts and the processes that make them. 

Computer modeling, Dr. Teter reasons, 
is perhaps the best tool because it allows 
researchers to simulate effects on the sub- 
stances that comprise their products. 
““With models, we can do our chemistry 
by throwing atoms in a box,” he explains, 
referring to computers as the box and nu- 
merical instructions as the atoms. ‘‘So we 
throw the atoms in this box, grind them 
down mathematically and let them cool. 
When you’re done, you have a crystal. 
Doing this by computer cuts the time in- 
volved in the experimental process by at 
least one order of magnitude.’’ 

In addition to Corning Glass, IBM also 
stands to benefit from Dr. Teter’s com- 
puter modeling. In what is termed a ‘‘co- 
operative testing environment,’ the ES/ 
9370 Model 90 and associated VM soft- 
ware is on loan to Corning’s research and 
development complex. As part of a joint 
study venture, IBM has agreed to let 
Corning operate the system for 18 months. 
Corning, in turn, will recommend possi- 
ble improvements relating to hardware, 
software, service and marketing. 

‘‘As a company that’s highly depend- 
ent on its research and development ef- 
fort, Corning Glass is ideal for testing the 
9370 in an engineering/scientific environ- 
ment,”’ points out Dick Sileo, an IBM ad- 
visory systems engineer for the Corning 
account. “‘Their researchers gain from the 
fact that with IBM’s systems, they can 
obtain quick visualizations of their sci- 
entific solutions. IBM gains because 
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ES/9370 & VM 


Corning is on the cutting edge of this 
technology and they can provide valuable 
technical direction for our hardware and 
software.” 

Although it has been an IBM customer 
for years, Corning, like many major users 
these days, is not ‘‘all IBM.’’ Systems 
from IBM and other competitors are in- 
stalled at many of the company’s 45 lo- 
cations worldwide. At Corning headquar- 
ters, for example, IBM equipment controls 
most commercial functions; DEC equip- 
ment controls most scientific and manu- 
facturing processes. 

According to Dr. Teter, the value of the 
IBM/Corning joint study relates to what 
can be learned about productivity. As the 
author of Corning’s ‘‘Finite Element Fluid 
Flow’’ modeling software, Dr. Teter is 
considered a top theorist in computer 
modeling and glass chemistry. Computer 
modeling, he explains, holds great prom- 
ise as a productivity tool for virtually all 
scientific disciplines. 

**My vision for the future of supercom- 
puting is that it will become the most cost- 
effective way to design and test new prod- 
ucts, processes and materials. Eventually 
hardware and computing cycles will be- 


come effectively free . . . we will be lim- 
ited by the number of truly capable people 
that we have. Consequently, my recom- 
mendation is to proceed aggressively with 
those factors which will increase the pro- 
ductivity of the people involved,’’ Dr. 
Teter says. 

The goal? Find radical new materials 
with which to ‘‘build’’ new products. ““By 
letting the computer do the repetitive work 
that the theorists already know how to do, 
we can spend time on solutions. That’s 
when the breakthroughs occur. That’s what 
this is all about,’ he concludes. = 
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Techniques 


cility/Program Development Facility 

(ISPF) is an editor and on-line DASD 
utility as was explained in my previous 
article, ‘“‘ISPF Spells Productivity,’ in 
the November/December, 1988 issue of 
MAINFRAME JOURNAL. 

According to IBM, ISPF can be used 
to quickly and economically develop and 
maintain applications — batch and inter- 
active. Programmers have convenient ac- 
cess to a set of tools used in all facets of 
on-line program development and testing. 
In short, ISPF offers an excellent full- 
screen editor and productive set of inter- 
active panels for executing utility func- 
tions: delete, define, copy, rename and list 
information about datasets. 

This article examines techniques that 
aid in making the use of ISPF more pro- 
ductive. These techniques include: 
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[aise System Productivity Fa- 


By Jon E. Pearkins 


® Moving around fast in files and in 
ISPF itself 

@ The value of sequence numbers 

@ Unprintable characters 

@ Never getting stuck 

@ Tabbing simplified 

@ Performance. 


LOCATE 


If you happen to look at the letter ‘*L” 
in the ISPF Help Index, you will see that 
the LOCATE Primary Command is one 
that can be used in various places in ISPF. 

If you fill in an ISPF Library’s name 
in the Browse or Edit Entry Panel but do 
not provide the name of the member you 
are interested in, you will see a Member 
Selection List listing the member names 
in alphabetical order along with statistics 


for each. For a large ISPF Library, scroll- 
ing forward (PF8) to the area of interest 
can be time-consuming. The LOCATE 
Command can be used to move directly 
to the area of interest. For example, if you 
know that the member you want begins 
with ICE, you can type LOCATE ICE to 
get to a list of all the members that start 
with ICE. 

Once you are actually browsing or ed- 
iting a file, the LOCATE Primary Com- 
mand again eliminates a lot of scrolling. 
If you are working on several parts of a 
file, you can label the first line of each 
part and use LOCATE to get you directly 
to the appropriate part at any time. If you 
called a part WS, you would type .WS 
on the Command Line (===>) in 
Browse to mark the first line displayed on 
the screen as WS. LOCATE .WS would 
bring you back to this part of the file at 
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any time during the current Browse. 

In Edit, you would use the Dot(.) Line 
Command to set up a label. Then, .WS 
would be typed over the sequence num- 
bers of the first line of the part of the file 
you want to call WS. As with Browse, 
LOCATE .WS would later bring you back 
to the WS part of the file. 

LOCATE can also be used with a num- 
ber. LOCATE 400 would take you to the 
400th line of the file in Browse. However 
in Edit it would take you to the line with 
a sequence number of 000400, usually the 
fourth line of a file RENUMbered to the 
default sequencing. This is useful when 
you are not sure where you are in the file 
since you can scroll a given number of 
lines by typing it in the SCROLL 
= = => field near the top of the screen. 


Tabbing 


Tabbing is probably the most confusing 
part of ISPF. There are three kinds of tabs 
in ISPF: hardware, software and logical. 
Hardware tabbing is never used by pro- 
grammers and software tabbing is used by 
ISPF internally to figure out where you 
might like the cursor placed after you hit 
Enter. Logical tabbing is normally what 
you would want to use. 

For logical tabbing, you must identify 
what columns are tab columns and what 
character you are going to use to save you 
from using the space bar. You need a keen 
eye to move to a column using the space 
bar. For example in Assembler, IBM’s 
standard columns are 10, 16, 35 and 72. 
In COBOL you might want 12, 16 and 
20 to provide a standard block indentation 
for readability. You normally would not 
specify column eight because if you use 
ISPF’s COBOL sequence numbering, the 
Editor will make it appear that column 
seven is the start of the line. 

Use the TABS and COLS Line Com- 
mands to display the tab positions. On the 
line created by the TABS Command, place 
an asterisk one column before each tab 
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Picture String Tips 


a ” 


<"” — lower-case letter 
“>" — upper-case letter 
“— ___ non-numeric character 


yy 


ny 


mow 
4 


— single digit, 0-9 


” — special character 


“ 


position. For example with Assembler, 
you would put asterisks in columns nine, 
15, 34 and 71. The asterisks are one char- 
acter ‘‘off’’ where you think they should 
be placed because they mark the end of 
each field. 

To start using the logical tab, you must 
define a logical tab character. If you find 
the back slash convenient, enter the Pri- 
mary Command: TABS \ 

Now you can start using it: \LA\ 
R15,4\WARNING RETURN CODE 

Tabs are part of the Editor’s Profile and 
will be applied to all ISPF Libraries with 
the same extension. 


Sequence Numbers 


ISPF sequence numbers are viewed by 
many programmers as a bother and are 
frequently disabled. Why? Because the 
usefulness of numbering as a method of 
change control is not widely understood. 
Standard sequence numbers go in the first 
eight columns of datasets with variable- 
length record format and the last eight 
columns for fixed-length record format. 
In the most common case, 80-byte, fixed- 
length record format sequence numbers 
go in columns 73 to 80. Assuming you 
have STATS ON, the last two digits (col- 
umns 79 and 80) indicate the Modifica- 
tion Level of the member when the line 
was last modified. This is vital informa- 
tion when trying to answer the first ques- 


Poe Ree oe 
//TAPELFIL =PROC  FILENUM = ,INSER = xxxxxx,OUTSER = xxxxxx 
//TAPEIFIL = EXEC PGM=IEBGENER,COND = (0,LT) 
//SYSUT1 DD  LABEL= (&FILE,BLP) VOL = (,RETAIN,SER = &INSER), 
// UNIT = TAPE,DCB = (RECFM = U,BLKSIZE = 32760), 
// DISP = (OLD,PASS) 
//SYSUT2 DD LABEL= (&FILE,NL) VOL = (,RETAIN SER = &OUTSER), 
// UNIT = TAPE,DCB = (RECFM = U,BLKSIZE = 32760), 
// DISP = (NEW,PASS) 
//SYSPRINT DD SYSOUT=* 
//SYSIN DD DUMMY 

Zz PEND 
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— any character that cannot be displayed 


— anything but a blank character 


P 
P 
pt. 
pt. 
P*@” — letters, either lower- or upper-case 
P 
P 
Pp 
P 


=" — match any character (for complex patterns) 


tion in problem determination, ‘‘What 
changed?”’ 

Before you add sequence numbers to a 
large file, it is a good idea to check to see 
if they will be overwriting any useful in- 
formation. If the file contains JCL, As- 
sembler, SORT or any other IBM utility 
statements, column 72 should also be 
checked because any characters there will 
be interpreted as Continuation Marks. A 
fast way to check for non-blanks in col- 
umns 72 to 80 is with the Picture String 
of the FIND Primary Command: FIND 
P‘*—”’ 72 80 (see Figure 1). 

To add sequence numbers to a file, use 
the Primary Command NUMBER ON. 
Initially the lines will be numbered by 
hundreds: the first line will be 100, the 
second 200 and so on. After modification, 
the file can be resequenced to the original 
hundred sequence by the RENUM Com- 
mand. On the other hand, if ISPF is num- 
bering a file that contains data that will 
be read by a program that expects all 80 
columns to be useful data (that is, a SYSIN 
dataset in JCL), you can blank out the 
sequence numbers and get ISPF to stop 
updating them by the UNNUM Com- 
mand. 

If you want to add sequence numbers 
to all members of a PDS or ISPF Library 
at once, 3.5 (Reset ISPF Statistics) will 
do that for you. Using the R option and 
answering NO to all but RESET SEQ 
NUMBERS, you can _ resequence all 
members in one operation. 

Sequence numbers can also be used 
when you need ascending numbers in your 
file for other purposes. For example, in 
an installation without any of the non-IBM 
packages you would use to make a copy 
of a tape, you can write an MVS batch 
in-line PROC that executes IEBGENER 
with the file number as the parameter and 
the volume serial numbers of the tapes 
coded on the header line of the PROC as 
in Figure 2. 


37 


If you have 120 unlabeled files (or 40 
labeled files) on the tape, as I did re- 
cently, it is easy to generate 120 lines 
that say: 

//COPYIFIL EXEC TAPEIFIL,FILE=n 

But to get the ‘‘n’’ in FILE= to sequence 
from one to 120 would seem to require a 
lot of (error-prone) keying. Here is how 
you can use sequence numbers to do it for 
you automatically: 


@ Create a new member 

@ Enter the NUMBER COBOL 
Primary Command 

@ Insert a blank line: I Line 
Command, then actually type a 
blank on the line somewhere and 
hit Enter 

@ Use the R119 Line Command to 
create a file with 120 blank lines 

@ Enter the NUMBER NOCOBOL 
Primary Command 

@ Then, BOUNDS 5 * 

@ On the first line, enter the ))99 Line 
Command (be sure to leave a space 
after the 99 or position it at the end 
of the sequence number) and on the 
last line, the )) Line Command 

@ Enter the BOUNDS Primary 
Command with no parameters to 
reset the column bounds to their 
original values 

@ Insert a new line at the top of the 
file: 

//COPY1FIL EXEC TAPEIFIL,FILE= 

@ Enter the COLS Line Command 
over the sequence number of this 
new line 

@ From the column numbers marked, 
you can determine that the numbers 
generated should start in column 
31. Hence, the numbers need to be 
shifted right 30 columns 

®@ On the second line, the first line 
with numbers, enter the ))30 Line 
Command; on the last line of the 
file, enter )) 

@ Enter the M (Move) Line 
Command on the first line of the 
file and 09999 on the second line. 
This will reMove the first line and 
Overlay it on to the second line and 
on all 9,999 lines that follow 

@ Add a job card and the in-line 
PROC definition (shown above) 
before the first line of the file. 


Unprintable Characters 


As mentioned above, FIND P*‘.’’ will 
locate any character in your file that can- 
not be displayed on your terminal. But 
there is no need to live in mortal fear of 
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unprintable characters in every file you 
use. Whenever you edit a file with ISPF, 
you will receive a warning message if the 
file contains any unprintable characters. 
FIND P**.”’ helps because it will give you 
the hexadecimal equivalent of each char- 
acter you find. What if you have a whole 
group of unprintable characters and want 
to see them all? FINDing one character at 
a time can be tedious. 

HEX ON is a Primary Command in both 
Browse and Edit that will display each 
line in both character and hexadecimal 
form. In Edit, a change to either the hex- 
adecimal digits or character displayed will 
result in a change to the file — extremely 
useful for lines with mixed unprintable 
and printable characters. 

Whether or not you have HEX ON, you 
can locate any unprintable character by its 
hexadecimal representation. FIND X**16”’ 
would locate the backspace control char- 
acter in either Browse or Edit. 

One final word about unprintable char- 
acters: ISPF only considers characters with 
hexadecimal codes less than X‘*40”’ 
(blank) worth bringing to your attention. 
Although the ISPF Editor will not give 
you a warning for an X‘*‘FF”’ in a file, it 
will be displayed as a period by Browse 
and can be located with the FIND P**.”’ 
Line Command in both Browse and Edit. 


Keeping Old Versions 


It is often advisable to keep an old copy 
of any file you are going to change in case 
the changes do not work. The Editor al- 
lows you to abandon your edit session with 
the CANCEL Primary Command. It is 
clear that more comprehensive methods 
are needed. 

One installation uses the convention of 
adding an @ to the name of the old copy 
of the member, if working with an ISPF 
Library and adding it to the second-to-last 
level of the dataset name otherwise. Where 
the member or level is already eight char- 
acters in length, the last character is re- 
placed by the @. In VM, the @ is added 
to the filename. 

The easiest way to create the backup 
member is with the Editor just before you 
change the file. Use the Line Command 
C9999 on the first line of the file and the 
CREATE name@ Primary Command. 
However this approach may eliminate 
valuable information maintained by ISPF 
Statistics. 

For each member, ISPF Statistics tell 
you: 

@ Creation date 

@ Date and time of last modification 


@ The user ID doing the last 

modification 

@ The number of times the member 

has been modified 

@ The number of lines in the member 

when it was created 

@ The number of lines in the member 

now 

@ How many current lines have been 

changed or added. 

This information is stored in the directory 
of the ISPF Library, but only if you have 
STATS ON (the default) when using the 
Editor to create or modify the member. 
Typically, members without statistics have 
been created by IBM or user programs 
rather than ISPF. 

Statistics do take space and creating 
them for an MVS PDS (which you can 
do for all members at once using 3.5 — 
Reset Statistics), may require an increase 
in the number of directory blocks allo- 
cated for the PDS. With Statistics, you 
will need one directory block for each six 
members. 

To preserve Statistics for both the new 
and backup versions of a member you are 
going to change, rename the member add- 
ing the @ sign and then use 3.3 to make 
a copy of the member without the @. The 
copy of the member without the @ can 
then be edited. 


Global Commands 


Up to now, we have concentrated on 
the ISPF Editor and Browse. The com- 
mands and techniques that follow can be 
used anywhere in ISPF (see Figure 3). 

Option 6 is not the only place where 
you can issue a TSO Command. If you 
precede any TSO Command with ‘‘TSO,”’ 
you can execute that command from the 
COMMAND = = => line of any ISPF 
screen. Following its completion, you are 
back where you started in the same ISPF 
panel. TSO STATUS can be used to save 
you from moving into 3.8 every time you 
want to find out the status of a batch job 
you are running. In VM ISPF, you would 
use ‘“CMS”’ before any valid VM/CMS 
Command. 

PRINT-HI and PRINTLHI will send 
copies of the ISPF panel you currently 
have displayed to the ISPF List File for 
later printing. The HI indicates that any 
highlighted portions of the screen will be 
double printed, making them bold on most 
printers. PRINT-HI prints the screen as 
you see it while PRINTLHI is useful in 
Split Screen Mode where it prints the 
complete logical screen of the current side 
of the Split Screen. 
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PF7 (UP) and PF8 (DOWN) are the 
normal ways of scrolling in ISPF. In the 
SCROLL ===> field in the upper 
right-hand corner, you can specify how 
much you want to move backward or for- 
ward in the file or list. PAGE will move 
you a full screenful of lines; DATA, one 
line less than a screenful; HALF, a half 
screenful. Specifying a number moves you 
that number of lines. CSR (cursor) will 
make the line where the cursor is the top 
(for PF8) or bottom (for PF7). If the line 
is already at the top or bottom, then the 
movement will be a full screenful of lines. 

The advantage of using PAGE, HALF, 
DATA and CSR rather than a number is 
that they adjust automatically when the 
screen size changes as it does if you use 
Split Screen or a 3270 terminal that al- 
lows more than 24 lines on the screen. 

You can also type MAX in the SCROLL 
= = => field to get to the top or bottom 
of the file. A much faster way of doing 
this is to type the letter M on the COM- 
MAND = = => line and hit PF7 or PF8. 
This works because ISPF takes the PF key 
meaning and concatenates it with any- 
thing found on the Command Line after 
inserting a blank. DOWN M is a legiti- 
mate command, ‘*‘M”’ being a legitimate 
abbreviation of MAX. 


Moving Around Fast 


The characters = . and ; help you move 
around in ISPF more quickly. Although 
PF4 takes you from any ISPF screen to 
the ISPF Main Menu, the = indicates that 
you want to use the Main Menu as your 
starting point. The number or letter fol- 
lowing the equal sign is the item on the 
Main Menu you want to choose. For ex- 
ample, =X would indicate you want to 
immediately exit ISPF (or terminate Split 
Screen Mode), while =3 would take you 
to the Utilities Menu. A period, and an- 
other number or letter following, indi- 
cates that you also want to specify a menu 
choice from the menu displayed as a re- 
sult of your (first) choice from the Main 
Menu. 

Assuming ; is the special character you 
choose for a Command Delimiter on the 


Help When You Are Stuck 


NULLS Primary Command — allows you to insert characters in a line 
RESET key — clear “Input Inhibited” to allow keyboard input again 
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Global Command Tips 
TSO — issue a TSO Command from the COMMAND Line of any screen 
CMS — issue a CMS Command from the COMMAND Line of any screen 
PRINT-HI — print the physical screen as you see it with bolding 


PRINTLHI — print one side of a Split Screen with bolding 
PF7 — scroll up the amount shown in the Command Line or Scroll Field 
PF8 — scroll down the amount shown in the Command Line or Scroll Field 


=m.n — go immediately to menu choice “y 


si 


on Main Menu item “x” 


=X — immediately exit ISPF; terminate one side of a Split Screen 


0.1 ISPF Terminal Characteristics Panel, 
you can do the equivalent of several en- 
tries on the COMMAND = = => line 
at the same time. This is especially useful 
in a dial-up or other situation in which 
the data communications speeds are slow 
(that is less than 9600 baud). For exam- 
ple, =2;;SEL FASTCOPY;CHANGE 
““CLASS = Q”’ ‘‘CLASS = P’’;SUBMIT; 
CANCEL; =3.8;L would submit a batch 
job after temporarily (CANCEL) altering 
the job class and then check on its status. 
Because you cannot use PF keys in the 
middle of the line, you will find yourself 
using some unfamiliar commands: the 
Primary Commands you normally hit PF 
keys to do. If you are using Split Screens, 
you will be surprised what you can do on 
one line if you include the SWAP Primary 
Command (PF9). 


When You Are Stuck 


The most common way to get stuck in 
the ISPF Editor is to try to insert char- 
acters into an existing line with NO- 
NULLS in effect (the default) or to insert 
characters in a newly-created line even 
with NULLS in effect (see Figure 4). ISPF 
fills all spaces on the line with blanks even 
after the end (last non-blank character) of 
the line. Trying to insert characters on a 
3270 terminal gives you an error that var- 
ies depending upon the model of 3270 
you have. Often, a stick man followed by 
a > is displayed in the Status Line at the 
bottom of the screen. Protocol convertors 
typically beep at you. A similar situation 
also exists when you forget you are in 
Browse and try to overtype characters in 


PA2 key — redisplay the entire screen 
PA1 key — to stop TSO Commands that are processing 
SYSTEM REQUEST key, then LOGOFF TYPE(UNCOND) — to sign off 
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the file. The error displayed is different 
but the result is the same: you cannot type 
anything more until you clear the condi- 
tion. The solution, too, is the same. Hit 
the RESET key on the 3270 terminal. 

What happens if you want to redisplay 
the entire screen? ISPF is smart: it will 
only write out those characters that need 
to be changed from its last write and your 
last entry on the screen. Data transmis- 
sion errors may have given you a different 
screen than ISPF thinks you have. Hitting 
the PA2 key on a 3270 terminal will get 
ISPF to redisplay the entire screen. PA2 
is also a good way to solve any of the 
following problems: 

@ You regret the changes you have 
typed since the last time you hit 
ENTER or one of the PF keys 

@ You accidentally hit the ERASE 
INPUT or CLEAR key on the 
3270. 

PAI can also be hit when you are in 
Option 6 (Enter TSO Command or CLIST) 
to halt the command or CLIST, but it is 
generally inadvisable elsewhere in ISPF. 

In a desperate situation in which you 
are really stuck and getting no response 
at all, you can force the system to log you 
off, stopping all processing you have re- 
quested. Hit the SYSTEM REQUEST key 
on the 3270. This key is often labeled 
SYS REQ and its use usually requires 
holding down the Alternate (ALT) key 
while hitting it. Then type LOGOFF 
TYPE(UNCOND). Note that this is a 
VTAM command and assume that you are 
running VTAM to control your terminal 
(which almost all installations do). 


Performance 


For performance reasons, a large num- 
ber of installations do not allow their MVS 
applications programmers to use ISPF un- 
der TSO. Instead, they are restricted to 
VM/CMS or a CICS-based editor and job 
submission/retrieval package. However 
other shops have found that, used with a 

See ISPF Techniques page 9/ 
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What’s new 
in 
MVS operations? 


Soon “Lights Out” will be the standard way of running 
large MVS datacenters. The service improvement and 
cost reduction available from an aggressive Automated 
System Operation implementation effort is too large 
to ignore. 

OPS/MVS from MVS Software is the only product 
that delivers the technology today required to achieve 
the promise of Automated System Operations (ASO). 

OPS/MVS earned The Gartner Group’s rating as “the 
top gun” Automated System Operations product 
because it has the functions and facilities that are re- 
quired to meet the demands of unattended operations: 

REXX language... Rule-based Automated Operations 

Facility... Interative automation testing support... 

Automation audit trail... OMEGAMON® interface... 

Message text independence...MCS console enhance- 

ment...Programmable Batch Operations Interface... 

Full-screen, menu-driven operations interface ...VM 

Guest Support...JES3 support... Multi-system commu- 

nication... Console Consolidation Facility ...Single point 


You're 
looking at it. 


..and it 
costs less 
than you 
think. 


of control... Outboard PC programmed in REXX... 

Remote operation... Pager support...IMS/DC and CICS 

Operation Facilities. ert System Interface ... 

MVS/ESA support. 

Our customers, with configurations varying in size 
from a single 4381 to multiple 3090-600s at multiple 
sites, agree: OPS/MVS is not only the most powerful 
product available; OPS/MVS is also the easiest product 
to use. And OPS/MVS is the only product designed for 
unattended operation of a major datacenter. 

OPS/MVS prices start at $9,500 for a 4381 running 
MVS/JES2. For more information on OPS/MVS, including 
pricing for your site’s CPU configuration, Contact us at 
12555 West Jefferson Blvd., Suite 221, Los Angeles, 
California 90066 or call 213-578-1147. 


MVS SOFTWARE, INC. 


The Automated System 
Operations Specialists 


CIRCLE #31 on Reader Service Card A 


Implements Expanded 
4 Addressing 


nterprise Systems Architecture or 
Res IBM’s new large system ar- 

chitecture, dramatically expands 
virtual addressing capabilities under MVS/ 
XA. A previous article, “ESA Is On The 
Way,” in the January, 1989 issue of MAIN- 
FRAME JOURNAL, described how this 
capability equips large installations to cope 
with processing requirements of the next 
decade. This article will examine how ESA 
implements this expanded addressing. 

The new ESA/370 architecture is imple- 
mented in the Enterprise System/3090 “E” 
and “S” Models and 4381's “E” Models. 
These processors contain additional hard- 
ware, new registers and the enriched in- 
struction set required to run ESA. 

The ESA architecture implements ex- 
panded addressing through new facilities 
collectively known as the Advanced Ad- 
dress Space Facility (AASF). The AASF 
facilities provide access to greatly in- 
creased quantities of virtual storage. They 
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simplify and improve the reliability of com- 
plex inter-address space communication. 
This article probes several of these AASF 
facilities namely the data space, Address 
Space Control (ASC) modes, access regis- 
ters and the linkage stack facility. 


Data Space 


One innovative concept in ESA is that of 
the data space. Programs can easily refer to 
data outside of their address space. Data 
spaces provide application programs im- 
mense data addressability allowing them to 
break out of the 2GB virtual storage limit 
imposed by the 370/XA architecture. Un- 
der ESA, a program can address 16TB 
(terabytes) that is 8,000 times greater than 
XA’s limit. 

Data Space Structure 

A data space is similar to an address 
space with 2GB of virtual storage. The data 
space contains nothing but data. Execut- 


able code can be stored in a data space but 
must be moved into an address space be- 
fore being executed. 

Figure 1 shows a simplified diagram of an 
application in an address space. The ad- 
dress space contains 2GB of virtual stor- 
age. Part of this storage, on both sides of 
the 16MB line, is used by the System Area 
for the nucleus, LPA, SQA and CSA. The 
application program’s executable code oc- 
cupies storage in the address space. The 
remaining virtual storage is available for 
data buffers for all files used by the 
program. 

In the simplified diagram, 2GB provides 
plenty of storage for both the program and 
an adequate quantity of buffers for three 
files. However, if this address space con- 
tains a subsystem, such as CICS, the avail- 
able storage could be shared by buffers for 
a hundred or more files. 

Figure 2 illustrates the same application 
under MVS/ESA. Two files now reside in 
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Virtual Storage Layout 
MVS/XA Address Space 
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Application 
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their own data spaces. The application pro- 
gram has full access to both data spaces as 
well as buffers for the other file in its own 
address space. 

As you can see in Figure 2, the entire 
2GB in the data space is devoted ex- 
clusively to data. No space is sacrificed to 
the system area or program code. 

Data spaces can be created and used 
directly by Assembler programs. High- 
level languages use data spaces through 
Data Windowing Services. A future article 
will explore more fully the ways data spaces 
satisfy a variety of needs. 


Data Space Benefits 

Each data space contains data from only 
one file. This data isolation helps prevent it 
from being corrupted by problems in the 
application’s address space. 

Data spaces also improve an applica- 
tion’s performance. When a program 
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needs data that is not in a buffer, the access 
method performs an I/O. As seen in Figure 
1, an address space can devote a limited 
amount of virtual storage for each file’s 
buffers. The result is a large amount of 
access method I/O. 

A data space, on the other hand, is 
nothing but data buffers. This drastically 
decreases access method I/O. A file with 
less than 2GB of data can be completely 
contained in the data space, eliminating 
access method I/O during processing. 

Because a data space consists of virtual 
storage, access method I/O may be re- 
placed by paging. While paging is consider- 
ably faster, it impacts the entire system. 
ESA’s performance, especially when using 
data spaces, will be even more dependent 
on adequate paging resources than XA. 


Address Space Control 
(ASC) Modes 


ESA reduces the difficulty a program 
has in communicating outside its address 
space by introducing a number of ASC 
modes. 


Evolution of Inter-Address Space 
Communication 


ASC modes are an extension to current 
Cross Memory Services (XMS). To under- 
stand them, look briefly at the develop- 
ment of XMS. 


Early MVS 


One of the main features of the 370 
architecture and MVS/370 is the integrity 
provided by the address space structure as 
shown in Figure 3. 

A separate address space is provided to 
each user whether batch job, TSO session 


Virtual Storage Layout 
MVS/ESA Address Space with Two Data Spaces 
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or major subsystem such as JES, IMS/DC 
and IMS/DB. Some storage, such as the 
nucleus, Link Pack Area (LPA) and Com- 
mon System Area (CSA) is used by all 
address spaces and placed in a Com- 
mon Area. 

Address spaces are in the Private Area, 
protecting each user’s program and data 
from the others. Each address space has its 
Own unique segment table controlling stor- 
age. A Control Register (CR 1) points to 
the active segment table. MVS controls 
which address space’s storage is used by 
changing the pointer in the control register. 

This architecture has a number of 
benefits. 


@ A single copy of common storage 
serves any number of address spaces. 

@ Each address space can use the max- 
imum range of virtual addresses in the 
Private Area. Available virtual storage 
does not vary with the number of users 
(address spaces). 

@ No address space can encroach on any 
other address space. Each address 
space can only access storage pointed 
to by its segment table. 

Communication between address spaces 

is possible but only indirectly. For example, 
the following steps take place for IMS/DB 
to fill a request by IMS/DC: 

1. IMS/DC places a data request in 

the CSA 

2. IMS/DC creates a Scheduler Request 
Block (SRB) requesting the IMS/DB 
address space to process the data at 
the CSA address 

3. MVS processes the SRB and passes 
the address to IMS/DB 

4. IMS/DB processes the request, plac- 

ing the result in the CSA 
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5. IMS/DB creates a SRB informing 
IMS/DC of the result of its request 

6. MVS processes the SRB and passes 
the address to IMS/DC 

7. IMS/DC retrieves the result 
from CSA. 


As you can see, inter-address space com- 
munication in early versions of MVS was 
complicated. Increased system activity re- 
vealed a number of other limitations of the 
single address space architecture. 

@ The amount of available virtual stor- 

age is limited. 

@ Storage protection is provided by pro- 
tect keys associated with an address 
space. 

@ Shared code and data reside in com- 
mon storage. In exchange for perfor- 
mance gains, common storage reduces 
virtual storage available to address 
spaces and sacrifices storage protec- 
tion within the common area. 

Cross Memory Services 

To avoid problems like these, MVS/SP 
introduced Cross Memory Services 
(XMS). 

XMS simplifies communication between 
two address spaces. Bill Carico provides an 
in-depth description of XMS in a series of 
articles in MAINFRAME JOURNAL be- 
ginning in July/August, 1988. 

Three separate services are provided 
by XMS. 

@ Data Movement: data can be moved 
directly between two address spaces 
without the SRB/CSA overhead. 

@ Data Sharing: a program in common 
storage can reference data in two ad- 
dress spaces. 

@ Program Sharing: a program execut- 
ing in one address space branches to a 
program in another address space. 

MVS/SP and XA use a dual address 
space structure to provide these Cross 
Memory Services. 

Each address space uses two control reg- 
isters that can point to separate segment 
tables. As with base MVS, CR 1 identifies 
the Primary segment table. Another con- 
trol register, CR 7, can point to an alternate 
or Secondary segment table. A bit in the 
PSW (bit 16) indicates whether the Pri- 
mary or Secondary Control Register is 
used for data addressing. 

This dual address space structure 
provides a number of advantages over the 
earlier MVS structure. 

@ Performance of inter-address space 

communication substantially improved. 

@ Some Virtual Storage Constraint Re- 
lief (VSCR) is provided by an address 
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space’s ability to access data in another 
address space. It is also provided by 
the movement of code and data from 
the common area into private address 
spaces. 

= Improved integrity as code and data 
move from common areas into iso- 
lated address spaces. 


XMS’s dual address space structure still 
has a number of limitations. 


@ Virtual storage remains constrained 
because only two address spaces (Pri- 
mary and Secondary) can be used si- 
multaneously and common storage 
consumes a portion of each address 
space. 

@ The typical address space contains 
both code and data, compromising 
integrity. 

@ While conceptually easy to compre- 
hend, the instructions to implement 
XMS, as Carico’s articles demon- 
strate, are complicated and difficult 
to use. 


Address Space Control 

(ASC) Modes 

ESA/370 provides a multiple address 
space structure that is an extension of 
XMS. Two PSW bits govern the ASC mode 
which designates the control register to be 
used when executing the current instruc- 
tion. Three control registers are used to 
point to different segment tables. Table 1 
summarizes the different ASC mode 
possibilities. 


Address Space Control Modes 


PSW Bit ASC Control 


16 «17 Mode Register 


CR 1 
CR7 
none 
CR 13 


Primary 
Secondary 
Access Register 


Maintaining compatibility with XMS, 
bit 16 switches between Primary and Sec- 
ondary ASC modes. The use of bit 17 is 
new with ESA. When on, bit 17 indicates 
either the use of the Home address space’s 
control register or the use of another new 
facility, Access Registers (ARs). 

When in the Primary, Secondary and 
AR ASC modes, instructions are fetched 
from the Primary address space. In the 
Home ASC mode, instructions are fetched 
from the Home address space. 

The ASC mode can be changed in sev- 
eral ways including the new SAC instruc- 


tion (Set Address Space Control). 
Programs in the problem state can use 
SAC to change between Primary and AR 
modes. However, a program must be priv- 
ileged to change to the Home mode. 

ESA’s multiple address space structure 
and ease of ASC mode switching is an im- 
provement over previous techniques. The 
real power in ESA comes from its new 
AR mode. 


Access Register 
Translation (ART) 


A program’ ability to reference multiple 
address and data spaces is implemented by 
new hardware in ESA/370 computers that 
provides Access Register Translation 
(ART). ART is analogous to the DAT func- 
tion that provides Dynamic Address Trans- 
lation for virtual storage. 

ART redirects virtual addresses prior to 
DAT processing. An address in a program 
running in one address space can refer to 
an address in another address or data 
space. 

Access Registers 

ESA/370 computers provide an addi- 
tional set of 16 registers called Access Regi- 
sters (AR). These registers are used to 
identify an address or data space for data 
fetching. 

Before ESA/370, with the exception of 
the XMS instructions, instructions and 
data always reside in the same address 
space. Data addresses are computed using 
the Base-Displacement Addressing tech- 
nique. The Base is an address (either 24 or 
31 bit) held in one of the 16 General Pur- 
pose Registers (GR). Figure 4 shows an 
instruction at address 1,000 moves 10 bytes 
from address 4,000 to 6,000. 

ARs are paired one-to-one with the 
GRs. An AR associates the base register 
with an address or data space. Using ARs, 
a program can simultaneously access 15 ad- 
dress or data spaces. 

ARs are used only for addressing. They 
cannot be used for arithmetic or indexing 
operations. Also, ARs are used only for 
data fetches, NOT instruction fetches. A 
program cannot branch across address 
spaces using an AR. 

When in AR ASC mode, as shown in 
Figure 5, the AR identifies the address 
space to which the base register applies. 

Here is the same MVC instruction run- 
ning in Address Space “A.” The contents of 
the GRs are unchanged. However, the con- 
tents of AR 5 specify Address Space “B.” 
The source of the data to be moved is ad- 
dress 4,000 in Address Space “B.” Sim- 
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ilarly, the destination is redirected, by 
AR 6, to location 6,000 in Data Space “C.” 
The AR specifies the target address or data 
space by means of an Access List Entry 
Token or ALET. 


Access List 


The Access List is a table that defines the 
address and data spaces that a task can 
access using ARs. The AR contains a 
token that serves as an index to an entry in 
the Access List. 

The Access List can hold up to 253 en- 
tries. Since each entry refers to a 2GB ad- 
dress or data space, the Access List 
provides the program with the ability to 
reference 16TB of virtual storage. 

ARs use the Access List for every data 
fetch when in AR ASC mode. Special 
ALETs, shown in Table 2, are used for 
frequently used address spaces. This by- 
passes AR translation overhead for most 
data references in AR mode without forc- 
ing the program into the tedious chore of 
constant mode switching. 


Tokens 

Address spaces are identified in the Ac- 
cess List by a Space Token or STOKEN. A 
STOKEN is conceptually similar to the 
ASID (Address Space Identifier). There 
are some notable differences between the 
two. The STOKEN identifies both address 
and data spaces; ASIDs only refer to ad- 
dress spaces. Also, the STOKEN is 64 bits 
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long, permitting more unique identifiers 
than the 16-bit ASID. In addition, the 
STOKEN remains unique throughout the 
life of the IPL. Unlike an ASID, a 
STOKEN will not be reused, eliminating 
many operational difficulties. 

IBM’s stated direction is to use 
STOKENs to identify address spaces to 
MVS services instead of ASIDs or ASCB 
addresses. The STOKEN is part of a larger 
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token for each task called a TTOKEN or 
Task Token. 

TTOKENs are 128-bit identifiers that 
describe a task. Like STOKENs, they are 
unique for the life of the IPL and are not 
reused as are TCB addresses. These new 
tokens make it possible to verify that the 
intended address space and task have not 
terminated. 


Access List Types 

There are two types of Access Lists: 
the Dispatchable Unit Access List 
(DU-AL) and the Primary Address Space 
Name Access List (PASN-AL). A program 
can acquire an ALET from either of 
its lists. 

MVS has a unique DU-AL for each 
work unit (TCB or SRB). Problem state 
programs can add and delete entries on 
its DU-AL. Every MVS address space 
also has a unique PASN-AL. Updating 
the PASN-AL is limited to programs in 
supervisor-state or with Key 0. 

This access list structure is a security 
feature that provides for the separation of 
data from problem programs while permit- 
ting major subsystems access to that data. 


Special ALET Values 


Address 
Space 
Primary 
Secondary 
Home 


Control 
Register 
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access package...why settle 
for just a piece of the pie? 


If all you want is access to your network, a number of software vendors can help you. 
But, if you want more than just a piece of a product, you need NCI from Westinghouse. 

Network Control Interface gives you the power of total network control. It is the only 
network access and control product available for MVS, MVS/XA, VSE and VM operating 
systems. In fact, regardless of the size and complexity of your VTAM network, NCI provides 
all your users with a single system image, with identical entry screens and procedures. 

Of course we give you single point entry for quick application access at the push of 
a single key. That’s the easy part. But we also provide application load balancing, logon 
queueing, unlimited exit processing and a dialog manager. ..powerful features to improve your 
productivity. ..without sacrificing system performance. 

NCI can read the contents of your security data base and dynamically build user 
menus, listing only applications the user is authorized to access...reducing user confusion and 
simplifying security administration. 

With NCI, you can customize menus to meet your specific user needs, or use some of 
the over 100 sample panels provided in our Starter System...the options are unlimited. 

To truly appreciate the power of NCI, we invite you to call or write us for a free, 
30-day trial. 

More than just simple network access... NCI from Westinghouse. 


Westinghouse Pa Be ae er Management Systems Software 
SOFTWARE SOLUTIONS __ Pritsturan pa 1s230 

(800) 348-3523 
(w) Westinghouse (412) 256-2900 in PA 
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Extended Authorization 
Index (EAX) 


MVS controls the ability to build and use 
access list entries through the Extended 
Authorization Index (EAX). The EAX is 
an extension to the Authorization Index 
(AX) used by XMS. Authorizations for 
different tasks running within the same ad- 
dress space can vary. EAX controls apply 
only to address spaces. EAX authorization 
is not required for data space access. 


Instructions and MVS Services 
for AR 


AR mode processing is designed to be as 
transparent as possible. However, it is a 
major extension to the 370/XA architec- 
ture. As such, there are effects in terms of 
machine instructions and MVS macros 
services. 


AR Instruction Support 

As described earlier, ARs are used to 
redirect addresses when retrieving data. 
Because this redirection is implemented in 
the data fetching hardware, the entire in- 
struction set, including vector instructions, 
gains the addressing benefits. 

An AR is used only when it corresponds 
to a base register. If the GR is used as an 
index register, the AR is ignored. A few 
new instructions, listed in Table 3, provide 
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New AR Instructions 


Function 
Load Access Multiple 


Store Access Multiple 
Set Access Register 
Extract Access Register 
Copy Access 

Load Address Extended 
Test Access Register 


AR control mechanisms such as loading, 
storing and copying. The new AR instruc- 
tions run in problem state. They can be 
executed whether or not the program is in 
AR mode. 
New MVS Services 

MVS also has a number of new services 
that support the use of the advanced ad- 
dress space functions. Table 4 shows some 
of the more important new services. 

Other MVS Services 

Existing MVS services, unless explicitly 
permitted, cannot be invoked when the 
program is in AR mode. This restriction 
applies to all services whether invoked by 
an SVC or a branch entry. The program 
must issue the SAC instruction to switch to 
Primary mode before using the service. 

MVS is gradually changing the services 
to support AR mode callers. Services that 


New AR Related Macros 


Name Function 

ALESERV ALE Service 
TESTART Test ART 

TCBTOKEN TCB Token 

LOCASCB Locate ASCB 

ATSET Authority Table Set 
AXRES Authorization Reserve 
STORAGE — Storage 


Description 

Controls of Access List Entries such as adding, 
deleting, searching and extracting 

Determines whether an ALET/EAX combination is 
currently valid without using it for reference 

Obtains the TTOKEN for a task; Verifies that the subject 
task has not terminated 

Converts an STOKEN to an ASCB address 

Grants authority to users of a specific EAX 

Reserves a value to be used as an EAX 

A front-end to GETMAIN/FREEMAIN to obtain and free 


storage within AR qualified address spaces 


Name Function 
PC Program Call 
BAKR Branch and Stack 


PR Program Return 


EREG Extract Registers 
ESTA Extract Stacked State 
MSTA Modify Stacked State 


46 


Linkage Stack Instructions 


Description 


Transfer control to another program after optionally 
stacking execution information 

Stack execution information and branch 

Restore execution information and return 

Loads specified AR or GP registers from the last 

stack entry 

Obtain state information (PSW, PASN, SASN) from the 
last stack entry 

Saves the contents of an even/odd register pair in the 
last stack entry 


Description 

Load multiple ARs from storage 

Store multiple ARs into storage 

Set an AR from a GP register 

Set a GP register from an AR 

Copy on AR into another AR 

Load address and set AR according to mode 
Determine whether ART will take place 


support AR mode invocation are suffixed 
with an “X.” Below is a list of MVS services 
that already support AR mode: 


ATTACHX SNAPX 
ESTAEX XCTLX 
LINKX SYNCHX 
SDUMPX 

Linkage Stack Facility 


ESA offers yet another feature to reduce 
complexity of program linkages thus sim- 
plifying multi-address space environments. 
The processor, instead of software, saves 
and restores linkage registers and status in 
a hardware-controlled stack. Besides being 
faster, this new facility improves the re- 
liability of complex linkages. 

Linkage Stacks 

The Linkage Stack (LS) is a secure area 
provided by MVS for each dispatchable 
unit (TCB or SRB). It is used to save a 
program’s execution and state information 
across a linkage. 

LS Storage 

LS storage is allocated in 4K sections 
each containing up to 24 entries. LS sec- 
tions can be chained together if more than 
24 entries are needed. 

This chaining permits LS storage to be 
acquired dynamically. It avoids two prob- 
lems common to stack structures: the re- 
quirement for preallocated, contiguous 
storage; and a fixed, limited number of 
entries on the stack. 

Linkage Stack Entries (LSE) 

Linkage stacks have three types of en- 
tries: Header Entry, Trailers Entry and 
State Entry. 

There is one header and trailer for cach 
4K LS section enabling the chaining. 

The State type LSEs are 168 bytes long 
and contain status information at the time 
of a program linkage. This information in- 
cludes: GRs 0-15; ARs 0-15; PASN & 
SASN; and Current PSW. 


Stack Handling Instructions 


Table 5 summarizes instructions that use 
the linkage stack. 


February 1989 


Program Call (PC) Stacking 

The PC instruction has a new stack op- 
tion. When requested, the PC instruction 
automatically creates a state type LSE sav- 
ing the GRs, ARs and other status infor- 
mation. The instruction may also replace 
the PSW-key, PSW-key-mask and the 
EAX. When the stack option is not spec- 
ified, the PC is compatible with existing 
software. 


Branch and Stack (BAKR) 

The new BAKR instruction is a varia- 
tion on the other linkage instructions: 
BALR and BASR. BAKR allows the link- 
age stack to be used on branch linkages 
within a single address space. It stacks the 
caller’s registers and status. 


Program Return (PR) 

PR is a new instruction that provides the 
return mechanism from a stacking call. It 
restores registers and status from the stack, 
removes the LSE and returns to the caller. 

Registers (both GR and AR) 15, 0 and 1 
are not restored from the stack. Since these 
registers are primarily used for parameter 
lists, return codes and the like, PR pre- 
serves their values. 


Other Linkage Stack Instructions 
The final three instructions, EREG, 
ESTA and MSTA provide additional func- 
tions of retrieving or modifying selected 
information in the LS. These instructions 
work with the current LSE, leaving the 
stack pointer unchanged. 


Associated Recovery Routines 

(ARR) 

The PC instruction’s enhanced linkage 
can identify an Associated Recovery Rou- 
tine (ARR). It eliminates the overhead of 
establishing and cancelling recovery en- 
vironments for subsystem programs en- 
tered using the PC instruction. 

ARRs are like automatic ESTAE recov- 
ery routines. The ARR is in effect while 
the PC routine is executing. It is not neces- 
sary to create or delete the recovery rou- 
tine with each call and return. 

ARRs can be stacked and percolated 
along with ESTAE routines. 

To establish an ARR, use the new 
ETDEF (Entry Table Descriptor Defini- 
tion) macro. ETDEF generates the PC En- 
try Table Descriptor specifying PC options 
such as: ASC mode, EAX, SASN as well 
as the ARR address. Once defined, the 
descriptor is in effect for subsequent PCs. 


Summary see Shae 
Some of ESA’s Advanced Address Space 
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Facilities were examined in this article. 
These facilities provide capabilities to ad- 
dress vast quantities of data required for 
forthcoming applications. AASF also sim- 
plifies and improves the reliability of multi- 
ple address space operation, a key element 
in the future environment. 

A future article will explore data spaces 
and hiperspaces and how MVS/ESA uses 
them to improve performance while in- 
creasing reliability and availability. = 
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REORGS? 


Don’t Waste Your lime! 


degraded DB2 performance caused by 

disorganized data? Only if you are 
prepared to spend two, four or even eight 
hours running the REORG and if you can 
find a window when the data is not needed 
so the job can be run. 


The DB2 REORG Utility 


Disorganized data is a major problem 
contributing to degraded DB2 perform- 
ance and higher resource utilization. It is 
also one of the easiest problems to solve. 
IBM designed the DB2 REORG utility to 
correct the problems caused by disorgan- 
ized data. However disorganized data has 
these same adverse effects on the REORG 
utility itself. For example: the DB2 
REORG utility requires one and one-half 
hours to reorganize one million rows of 
15-percent disorganized data. It takes just 
12% minutes when this data is already 
organized. 

The DB2 REORG utility has six phases, 
each processed serially: 

* UTILINIT — utility set up and initiali- 
zation 

* UNLOAD — writes all data in the ta- 
blespace to a sequential dataset 

* RELOAD — loads the data back into 
the tablespace and also extracts index 
keys 

¢ SORT — sorts index keys extracted by 
RELOAD 


I: IBM’s REORG utility the answer to 
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¢ BUILD — builds all indexes if any exist 
* UTILTERM — utility clean-up and ter- 
mination. 

The UNLOAD phase uses most of the 
reorganization time. It uses the DB2 data 
manager to unload each row, one by one. 
When a clustering index exists for a sin- 
gle tablespace, DB2 uses it to unload the 
rows in cluster order. 

A problem occurs when the rows are 
taken out of cluster order. Then DB2 reads 
several pages more than once. Indirect 
references make this situation worse by 
causing even more I/Os. Extra I/Os gen- 
erate increased DB2 buffer manager ac- 
tivity that affects all users. 

If no clustering index exists or if the 
tablespace contains multiple tables, DB2 
unloads the rows using a sequential scan. 
This scan is faster than using an index but 
the rows are not reloaded in any particular 
order (no clustering). This process also 
increases buffer manager activity. 

The UNLOAD phase writes the rows 
to a sequential file that is, in turn, read 
during the RELOAD phase. Reloading the 
data consists of reading data from .the 
UNLOAD file and rebuilding the data 
pages of the tablespace. This process is 
relatively faster than UNLOAD but still 
uses the DB2 data manager. 

Another task of the RELOAD phase is 
to create the work file used to build the 
indexes. It extracts the keys for all de- 


fined indexes and writes a record for each 
to the work file. A single table, contain- 
ing 500,000 rows with a clustering index 
and two secondary indexes, creates 
1,500,000 work file records. Each record 
in the work file contains the index num- 
ber, the key value and the new RID of the 
associated row. 

The SORT phase sorts the records by 
index number and key value. This sort 
arranges, in order, all of the records for 
the first key then the second key and so 
on. When using a clustering index to un- 
load the rows, some redundancy occurs 
since the data is already in clustering key 
sequence. 

The BUILD phase uses the output of 
the SORT phase to build all of the indexes 
associated with the tablespace. It builds 
each index, one at a time, using the key 
value and the new RID assigned during 
RELOAD. Typically, the BUILD phase 
is shorter than RELOAD. However a ta- 
blespace with many indexes will spend 
considerable time in the BUILD phase. 

So, what benefit can be derived from 
the time and resources required for reor- 
ganizations? 

DB2 performance problems can be re- 
solved, although the solution is temporary 
if the tablespace is subject to constant up- 
dating. Also, the data is available READ- 
ONLY during UNLOAD and completely 
inaccessible during the remaining phases. 
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Periodic data reorganization is inevitable; 
therefore, shortening the time it requires 
becomes essential. 


Improving the DB2 
REORG Utility 


Optimal performance by maintaining 
organized data requires DB2 users to bal- 
ance degraded performance against time 
needed for reorganization. Another prob- 
lem, deciding when to reorganize data, 
develops and this is not an easy problem 
to solve. Ultimately the solution is two- 
fold: to have sufficient statistical data to 
predict the need for REORG and to sig- 
nificantly lessen the time it takes to do 
reorganizations by using a fast REORG 
utility. 

This fast REORG utility uses the stand- 
ard tools made available by IBM through 
the MVS/XA operating system. These 
tools are: VSAM control interval pro- 
cessing, track length buffers, efficient 
blocksizes and multitasking. Intelligent 
processing and these tools go a long way 
to reduce the time required to complete 
the reorganization of a DB2 tablespace. 

In using these tools, the area with the 
most opportunity for improvement is I/O. 
DB2 has an excellent data manager that 
supports a buffer pool of unprecedented 
size and uses state-of-the-art management 
techniques. However it suffers from the 
drawback of being a general-purpose I/O 
subsystem. It must serve multiple users, 
each with a different purpose. It also ex- 
ecutes in a separate address space from 
the application where the data is needed. 
This general-purpose cripples a highly- 
specific function like REORG. 

A single-purpose, efficient I/O design 
provides substantial improvements over 
the data manager. Since the intent is to 
improve a single function, the reorgani- 
zation of tablespaces, specialized I/O is 
essential. The foundation for this im- 
proved I/O subsystem is VSAM asyn- 
chronous control interval processing with 
sequential read-ahead. 

When a tablespace contains a single ta- 
ble, DB2 uses the clustering index, if de- 
fined, to unload the rows. It also follows 
indirection when encountered. Since a 
REORG is being run, the data is either 
out of cluster order, has substantial indi- 
rection or both. 

These conditions cause DB2 to access 
pages in a random order. They also cause 
it to read pages more than once. Avoiding 
use of the clustering index and ignoring 
indirection allows unloading each dataset 
of a tablespace sequentially. Sequential 
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I/O coupled with appropriate buffering al- 
lows VSAM to show its true colors as a 
high performance access method. 

Proper buffering is an essential com- 
ponent of high speed VSAM I/O. Check- 
ing the device type on which the dataset 
resides allows determination of the num- 
ber of control intervals per track. Using 
this many data buffers means that the 
number of EXCPs required to read the 
data will equal the number of tracks con- 
taining data. Assigning twice this number 
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allows VSAM to do sequential read-ahead. 
Sequential read-ahead reduces the num- 
ber of waits issued for I/O completion. 
Cylinder size buffering will reduce the 
number of EXCPs but is detrimental to 
the goal of reducing elapsed time. VSAM 
spends more time in buffer management 
and, therefore, significantly less memory 
is available for other uses. 

If the tablespace is partitioned, the use 
of multitasking and parallel processing 
provides an even greater improvement. 
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Succeed 


PLATINUM technology, inc. 
The DB2 Company” 


PLATINUM technology, inc. is the only full service 
software company specializing exclusively in DB2. 
All our effort and energy is focused on delivering 
the broadest array of quality solutions for the DB2 
user. As a result, IBM® has designated PLATINUM 
a Business Partner through the Authorized Applica- 
tion Specialist program specifically for DB2. 


PLATINUM PRODUCTS 


PLATINUM offers a complete line of software tools, 
education, and published products to ensure your 
success with DB2. 


Software Products 

The PLATINUM product portfolio consists of a 
complete family of administration, development, 
and end user DB2 software products. All are compat- 
ible with DB2 V1.3 & V2.1. The software products 
include: 

© RC/Query™ - Acomprehensive DB2 catalog 
query tool. 

© RC/Update™ - The industry’s best DB2 object 
management and data editing tool. 

© RC/Migrator™ - Acomplete object and data 
migration tool. 

@ RC/Secure™ - An extensive DB2 security 
management tool. 

@ PLATINUM Database Analyzer™ -The DB2 
database and DASD analysis, audit, and 
management tool. 

@ PLATINUM Report Facility’ - The DB2 
query and reporting system for developers and 
end users operating inTSO and CICS 
environments. 


DB2 Education Courses 
A complete series of hands-on DB2 training courses. 
PLATINUM courses cover all aspects of DB2, QMF, 
and CSP. All courses are available either at your 
facility or at our Corporate Education Center. 

@ Introduction to DB2 

@ DB2/SQL Application Programming 

®@ DB2 Application Planning and Database Design 

®@ DB2 Database and System Administration 

@ Using DB2 and QMF 

@ CSP Application Programming 


Published Products 
The most recognized and authoritative DB2 standards, 
methods, and guidelines for DB2 implementation. 


@ PLATINUM DB2 Guide/Online™ - The 
industry's leading standards manual for design, 
development, and administration of DB2 systems. 

@ The PLATINUM Reference™ for DB2 - The 
quick, pocket-sized reference for DB2 
information. 


Support 

All products and services carry our PLATINUM 
Quality Assurance Guarantee. Support is available 
24 hours a day, 7 days a week via our toll-free hot line. 


WORLDWIDE AVAILABILITY 
PLATINUM’s products and services are available 
around the world through our Affiliate Network. 
PLATINUM'’s full service capabilities include local 
support, education, and superior DB2 professional 
services. 
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; PLATINUM technology, inc. 
555 WatersEdge Drive 
Lombard, IL 60148-9930 
(312) 620-5000 FAX (312) 953-1923 


For further information, in-house demonstration, or 
our exclusive no-obligation product evaluation call: 


1-800-442-6861 
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One task can unload several partitions at 
once. Using asynchronous I/O and main- 
taining reads for each partition reduces 
the number of waits issued for I/O com- 
pletion. By dividing the partitions among 
multiple tasks, work is performed even if 
a task must wait for an I/O operation to 
finish (see Figure 1). 

Unloading the rows sequentially re- 
quires sorting to place them in cluster key 
order. By sorting the rows during the UN- 
LOAD phase, each task sorts only the 
portion assigned to it for unloading. This 
approach provides two benefits: it reduces 
the number of rows into each sort and it 
allows several sorts to be active concur- 
rently. 

If the tablespace is partitioned, the out- 
put of each sort is written to a single file. 
If the tablespace is not partitioned, a big 
improvement is still gained through asyn- 
chronous I/O. Also, sequentially unload- 
ing the data and then sorting it is faster 
than following the cluster index. Com- 
bining the data from each partition al- 
lows reloading of multiple partitions in 
parallel. 

Placing most of the burden on the UN- 
LOAD phase provides another benefit. 
Assigning the new RIDs during unload 
allows creation of work file(s) containing 
the secondary index data. Now it is pos- 
sible to build the secondary indexes at the 
same time the data is reloaded. DB2 cre- 
ates the work file during the RELOAD 
phase. This approach must wait until after 
all the data is reloaded to build the sec- 
ondary indexes. 

Assigning the new RIDs during unload 
also allows determination of the exact 
number of pages required for each parti- 
tion of the reload. When running with the 
UNLOAD PAUSE option, the partitions 
can be reallocated accurately and the re- 
organization started. 

The RELOAD phase also benefits from 
parallel processing and multitasking. The 
DB2 REORG utility uses three separate 
phases to rebuild the tablespace. These 
phases, RELOAD, SORT and BUILD, 
run serially. Combining these three phases 
into one will significantly reduce the time 
it takes to reorganize a tablespace. 

The mixing of records in the UNLOAD 
file sets up reloading of partitions in par- 
allel. Assigning the new RIDs during un- 
load permits building of the clustering in- 
dexes at the same time the data is reloaded. 
Using asynchronous I/O, the tablespace 
RELOAD process becomes an I/O man- 
ager driven by the UNLOAD process (see 
Figure 2). 
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Getting Organized with DB2: 
Storing and Accessing Data 


In order to understand how DB2 stores and accesses data, you first need a short 
explanation of some important DB2 terms. 

Database is the logical representation of one or more DB2 objects. It names a 
collection of tables and indexes along with the tablespaces and index spaces in 
which they reside. 

Tablespace names a physical area of DASD storage containing one or more 
tables. It consists of one to 64 VSAM datasets containing up to 64 gigabytes of 
data. A tablespace contains one or more tables and is the unit of reorganization or 
recovery within DB2. 

Table is a collection of rows all having the same columns. DB2 stores all data 
in tables. 

Row is an ordered set of columns containing a single record of data. One or 
more rows comprise the data in a table. 

Column is a single field of data stored in a row. One or more columns comprise 
the data in a row. 

There are two ways DB2 can locate a row in a tablespace: by using an index or 
scanning the entire tablespace. When no index is available, DB2 scans the entire 
tablespace sequentially until it locates the desired data. If the tablespace contains 
more than one table, the scan may inspect data from any or all of the tables. 

It is possible to use a key to locate data when one or more indexes exist for the 
table. Each row in a tablespace has an address known as a Record Identification 
(RID). The RID contains the page number and slot within that page of where the 
row resides. If the DB2 optimizer chooses an index as its access path, DB2 uses 
the RID of the desired row to address the page and row directly (see Figure 3). 

Four types of update activity that are the major contributors to performance 
degradation within DB2 are: dropping tables, deleting rows, inserting new rows in 
a table with an index and increasing the length of data in VARCHAR columns. To 
illustrate these activities, we will use the PERSONNEL table from Figure 3. 

Suppose that, just after loading the table, the programmer dropped it by mistake. 
To correct the problem, the programmer redefined the table and again loaded the 
PERSONNEL data. Dropping a table removes the existence of the table and its 
associated data from the DB2 catalog. It does not free the space occupied by the 
data. Space occupied by dropped tables remains unusable within the tablespace 
until reclaimed by reorganization. Sequential scans of the tablespace include the 


DATABASE 


TABLESPACE 
PERSONNEL TABLE 
COLUMNS-->| EMPNO 


TITLE SALARY EXMP 


$99,999 
$75,000 
$62,500 
$13,500 
$50,000 


INDEXSPACE 
EMPNO INDEX 


00000101 
00000102 
00000103 
00000201 
00000202 


KEYS---> <—=—-RIDS 
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rows from dropped tables. This perusal of useless data causes increased I/O activity 
and CPU utilization. 

Deciding that selling flowers on the street corner is a less stressful occupation, 
the programmer decides to take early retirement. Prior to leaving, he deletes his 
information from the PERSONNEL table. DB2 marks the area occupied by the 
deleted row as free space. Free space is available for storing new information added 
in the future. Maintaining free space is essential to a DBMS like DB2, but can 
cause performance problems. 

Seeing the problems created by inexperienced programmers, the company hires 
five capable DB2 programmers. They quickly add themselves to the PERSONNEL 
table in order to get paid. DB2 inserts the information for the first new programmer 
in the free space made available when the original programmer deleted his infor- 
mation. The remaining four new programmers are inserted at the end of the table. 
Now, however, the rows are no longer in the same sequence as the employee 
number index. Using the index to access the data requires DB2 to read some pages 
more than once causing increased I/O activity and CPU utilization. 

After two months of steady business, one of the new programmers clearly ex- 
hibits superior leadership abilities. The company, pleased with his performance, 
promotes the programmer to manager of DB2 services. Now that the programmer’s 
title is longer, the information does not fit into its original location. In this case, 
DB2 stores the entire row at a new position large enough to hold the data. Reflecting 
this change in every possible index is extremely time-consuming. Instead, DB2 
marks the old location as a pointer and stores the RID of the new location at the 
old one. Now the index does not point to the actual data. Rather, it points to the 
page and slot that contains the RID of the actual data. This indirect reference 
requires an extra I/O to retrieve the row. Also, the free space returned to the 
tablespace is less than the original row length. It is less by the amount needed to 
hold the new RID and indirect reference indicator. 

This illustration will give you a basic understanding of how update activity causes 
tablespaces to become disorganzied (see Figures 4 and 5). Apply the principles 
illustrated above to a large order entry system and you can see the effect they have 
on I/O and CPU resources. 

Bill Cunningham 


Pl eh 0 hes 


DATABASE 


TABLESPACE 


PERSONNEL TABLE INDEXSPACE 


COLUMNS -~> EMPNO INDEX 
00000203 
00000301 
00000302 
00000401 
00000303 
00000402 
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00000501 
00000502 


ENGN) ’ 
indirection pointer to RID 503 
JANITO! 50,00: 


KEYS---> <~-=RIDS 


Problems Caused By Update Activities 


* Dropping tables — causes large areas of unusable data space that must be 
inspected during scan operations 
— increases |/Os 
— increases CPU utilization 


* Deleting rows — causes fragmented free space that may or may not hold future 
data 


— increases |/Os 
— can increase CPU utilization trying to locate free space 


«Inserting new rows with an index — causes the data to be out of sequence with 
the index 
— increases |/Os 


«Increasing size of VARCHAR values — causes data indirection 
— Increases |/Os 


—— DBZ Reores 


Building the secondary indexes using 
the data in the work file(s), created during 
the UNLOAD phase, are in clustering se- 
quence. Sorting by secondary index value 
places the data in proper order. DB2 does 
this sorting as a separate phase and writes 
the data to an intermediate dataset. This, 
in turn, involves more I/O. DB2 then reads 
this to the intermediate file during the 
BUILD phase, that involves more I/O. 

Using a separate task-per-work file al- 
lows simultaneous building of the in- 
dexes. Each task sorts the data and builds 
the indexes without intermediate work 
files. This approach to tablespace organ- 
ization provides tremendous reductions in 
both elapsed and CPU times. 

A benchmark used to test a prototype 
of this design is diagrammed below: 

* IBM 3084Q with 96MB of real memory 

* MVS/XA 2.2 and DB2 1.3 under VM/ 
SF (two dedicated processors and 48MB 
of real memory) 

* 1,000,000 rows of data, 15 percent out 
of cluster order 

* Average row length: 225 bytes 

* Clustering index. 

DB2 takes one hour and 47 minutes 
elapsed time and 10.5 minutes CPU time 
to reorganize the tablespace. The method 
outlined in this article takes just under 12 
minutes elapsed time and 2.25 minutes 
CPU time. This is an 89 percent reduction 
in the time it takes to reorganize the ta- 
blespace plus a 79 percent reduction in 
CPU costs. 


Conclusion 


The era of DB2 is unfolding. DB2 is 
rapidly becoming an integral part of pro- 
duction computer applications. It offers 
application development that is less time 
consuming and does not require the tech- 
nical knowledge of earlier database man- 
agement systems. 

DB2 provides the power and the ease 
of use rquired by today’s information sys- 
tems. This power and ease of operation 
puts the benefits of DBMS into the hands 
of many more users, thereby increasing 
the need for quick solutions to perform- 
ance and resouce utilization problems. = 
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The Applications 


Development Viewpoint 


apacity Planning (CP) deals with 
i user demand on a computing com- 

plex. In addition, it encompasses 
technical minutiae such as disk I/O per 
second, virtual storage occupancy and 
CPU wait/busy ratios. These ratios are 
used, for example, to predict the month 
in which a new mainframe must be 
brought on-line. Since a month’s interest 
on the $10 million outlay for a mainframe 
is $80,000, CP can be much more than 
an intellectual exercise. 
Capacity Planning in 
the Abstract 


For the purpose of this article, the dis- 
cipline of CP is the process of forecasting 
the workload and data storage require- 
ments of an Electronic Data Processing 
(EDP) complex for the purpose of meet- 
ing service level objectives in the face of 
a changing level of demand on the re- 
source. A quick review of the terms used 
in this definition follows. 


It is a forecasting process because the 
demand level (workload and data 
storage) changes over time. Absent 
this, you are a lucky person because 
you do not need CP. 
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The workload can be composed of a 
variety of elements, including busi- 
Ness transaction processing, time- 
sharing and batch work. 


« The data storage of prime concern is 
disk. 


» Service-level objectives can include 
on-line response time and application 
availability to users. 


If maintenance of consistent on-line re- 
sponse times is an objective, then CP must 
address itself to workload peaks rather than 
averages. This has the happy effect of fo- 
cusing the planner’s objective and discus- 
sions on a specifically identifiable grail. 

When on-line application availability is 
an objective, CP must deal with one or 
both of the following issues: scheduled 
outages of the application and the ‘‘other 
kind’’ of outages of the application. In 
the former case, consider a CICS/VS re- 
gion that has to be shut down periodically 
for batch processing of its databases. De- 
mands for longer CICS uptime can cause 
this so-called ‘‘batch window’’ to shrink 
to the point that more hardware must be 
planned to finish the batch work on time. 


Batch requirements thus enter CP’s scope 
of effort due to the force they exert against 
the CICS operational schedule. 

As for the ‘‘other kind’’ of application 
outages, CP may be employed if these 
outages pose a survival-level threat to the 
enterprise. Having little experience in this 
area, I will take the opportunity to avoid 
a subject that just makes people unhappy 
anyway. 


Kaiser Foundation 
Health Plan, Inc. 


The company is the northern California 
component of a nationwide membership- 
based prepaid health care program. In this 
region, Kaiser owns and operates 26 med- 
ical centers and clinics that are connected 
to an IBM-based central data center. The 
medical facilities being of differing sizes, 
each contributes a different share to the 
computer workload. Using MVS/XA, 10 
“‘production’’ CICS regions are run on a 
3090-300E and 3090-400. Other work- 
load is primarily composed of CICS test- 
ing, TSO and batch on a 3081KX and a 
3090-300E with a high percentage of the 
disks shared among the four machines. 
Most of the operational data is managed 


February 1989 


—Capacity Planning— 


by IMS/DB and DB2 on the two produc- 
tion CICS machines. 

Three applications dominate the CICS 
workload: 


= Patient Appointment, Registration 
and Reporting System (PARRS) 

® Medical Records Management Sys- 
tem (MRMS) 

« Admission, Discharge and Transfer 
System (ADT). 


Each of these three applications is only 
partly installed in the sense that not all of 
the medical facilities are using them yet. 
As hardware is installed and users are 
trained, the workload increases in a step- 
wise fashion. On a peak day, around two 
million CICS transactions are sustained 
across the two production machines with 
short-term peaks of 70 transactions per 
second. There are other large applications 
on the way to implementation. 

PARRS is used by about 1,000 apoint- 
ment clerks dealing with patients on the 
telephone. It is primarily a day-shift ap- 
plication and the biggest of the three ap- 
plications in terms of computer consump- 
tion. It has a predictable and significant 
Monday morning peak. There is annual 
seasonality as well. During Monday 
mornings in the winter, the action gets 
fierce with 30 appointments booked every 
minute during the peak two-hour period. 
PARRS will book around 11 million ap- 
pointments per year when it is installed 
in every ‘“‘appointed’’ patient service de- 
partment of all 26 medical facilities. 

MRMS deals with patient medical rec- 
ords in paper jackets. It is used to keep 
record room inventories and to track sign- 
ing-in and -out records among record 
rooms and medical personnel who use 
them. It has three separately installable 
components: inpatient record jackets, out- 
patient record jackets and X-ray photo 
jackets. MRMS is a day-shift application 
and, due to outpatient records represent- 
ing most of the action, experiences annual 
seasonality consonant with PARRS. Its 
weekday peak is less distinct than that of 
PARRS. 

ADT is used to record data concerned 
with the admission of an inpatient, the 
various care units to which he might be 
transferred within the hospital and dis- 
charge from the hospital. It requires a high 
scheduled uptime with 24-hour operation 
as the ideal. There is little annual season- 
ality; however, different medical facilities 
have different weekday peaks. Running 
at all 14 of the medical facilities that ad- 
mit patients, ADT serves 200,000 hos- 
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pitalizations per year, including one-day 
surgeries. 


Capacity Planning Incarnate 


I represent the application development 
group in CP. Four other planners are drawn 
from the MVS and CICS systems pro- 
gramming groups and the data adminis- 
tration group. For each of us, CP repre- 
sents a small fraction of our work time 
(for which we are grateful). 

There are several reasons why we are 
grateful. The forecasting process is diffi- 
cult especially in light of seasonal and 
random variations in patient activity. 
Then, due to the fact that the forecast data 
and application implementation schedules 
are by definition rather ‘‘soft,’’ the CP 
process is subject to second-guessing by 
whoever wishes to challenge our work. 
Nevertheless, it is fascinating. 

For application developers, capacity 
planning is primarily a twofold concept: 
CICS transaction workload and disk oc- 
cupancy. We do not need to plan for CPU 
seconds or virtual storage or I/O rates. 
That is not our part of the job. Our job is 
to express capacity consumption in terms 
of Natural Business Units (NBUs) that can 
be related mathematically to the nuts and 
bolts of computer system capacity. 

An NBU is an application-specific unit 
of consumption that relates to the real- 
world activity that caused the consump- 
tion. If the quantity of a given NBU dou- 
bles, the computer resource consumption 
should double. If the NBU quantity goes 
down by 10 percent, the computer re- 
source consumption should do the same 
and so forth. There are several types of 
NBU by which computer workload and 
disk occupancy are characterized. 

A Workload NBU (WNBU) is used to 
express the CICS workload caused by an 
application. My CP colleagues can relate 
these to actual CICS resource consump- 
tion via the CICS Monitoring Facility 
(CMF) and Resource Measurement Facil- 
ity (RMF) statistics. 

A Disk NBU (DNBU) is used to ex- 
press disk occupancy. The number of 
DNBUs is determined partly by the work- 
load (and resultant data growth) and partly 
by our data retention policy (that is, how 
long a historic record remains on file). 
The embodiment of a DNBU is, in our 
database scheme, a record stored either in 
DB2 or the IMS/DB database manage- 
ment system. It is preferable to declare a 
small number of *‘major’” DNBU types 
for each Application Function (AF). The 
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application developers can use rules of 
thumb and the entity-relationship diagram 
to determine what other records will exist 
due to the existence of the major records. 
Knowing the bytes consumed by the var- 
ious major and tributary records, they can 
relate each different major DNBU in- 
stance to actual disk bytes consumed. We 
can account for non-database disk files in 
the same general fashion. 


CP Example 


To make sense of this, the Medical 
Records Management System will be used 
as an example. There are four reasons why 
it represents a complex case of capacity 
planning. 

The first reason is that MRMS is com- 
posed of three subsystems: inpatient med- 
ical records, outpatient medical records 
and X-ray records. They do not all need 
to be installed as a unit. Therefore we 


Capacity planning 
is a twofold concept: 
CICS transaction 
workload and 
disk occupancy. 


must do capacity planning for the re- 
source consumption of each of the three 
subsystems separately. Each subsystem is 
called an AF, An AF is a complete appli- 
cation or a major subsystem of one if the 
subsystems are separately installable. 
Second, the workload of the three 
MRMS AFs is characterized by three dif- 
ferent types of WNBU: inpatient admis- 
sion (the inpatient record WNBU), out- 
patient visit (the outpatient record WNBU) 
and X-ray visit (the X-ray WNBU). It is 
unimportant that MRMS does not admit 
patients or register outpatient visits. What 
is important is that these WNBUs should 
correlate reasonably well to the MRMS 
workload and that the company accumu- 
lates, forecasts and internally publishes 
statistics on these metrics. Each of these 
WNBU metrics corresponds to an MRMS 
AF. To add to the complexity, CICS trans- 
actions in each of the three MRMS AFs 
present differing amounts of resource 
consumption in the EDP complex. 
Third, MRMS has six basic types of 
DNBU: the existing inventory of inpatient 
records, outpatient records, X-ray folders 
plus incremental inpatient records, out- 
patient records and X-ray folders created 


at the medical facilities by the ongoing 
workload. The MRMS data store is com- 
plex, using both IMS databases and non- 
IMS VSAM and QSAM disk files. 
Fourth, MRMS workload and disk oc- 
cupancy will change over time because it 
is not yet installed at all medical facilities. 
We need to express the NBUs done by 
existing MRMS AFs, those to be done by 
future installations of the AFs and incre- 
mental ones due to business growth. 


Application Functions 


In MRMS each AF has it own WNBU 
(admission, outpatient visit and X-ray 
visit). Each WNBU uses a different 
amount of the CICS resource and it is 
necessary to relate these WNBUs to the 
system software monitoring statistics. The 
CICS statistics from CMF are tallied for 
each of the various four-character CICS 
transaction IDs (Transids) rather than for 
each application program. Therefore in 
order to do capacity planning, there should 
be a standard that each AF should tend to 
have a set of Transids that apply to that 
AF only. (Transids consisting of a menu 
transaction from which the user may se- 
lect different AFs are an obvious excep- 
tion to this standard.) If all three MRMS 
AFs ran under the same set of Transids, 
there would be no way to relate the CMF 
Statistics to each of the three AFs that 
comprise the application. 

The foregoing sounds complicated un- 
til you consider the underlying simplifi- 
cations that are presented in the sequel to 
this article in the next issue. We have, as 
a fast-growing shop, about as simplified 
a version of capacity planning as we can 
get away with and still have reasonable 
confidence in the results. 

= Start by counting the number of 
DNBUs of the existing records in- 
ventory for each record room (inpa- 
tient, outpatient and X-ray) for each 
MRMS AF currently installed at each 
medical facility individually. 

©" Then, count the number of WNBUs 
pertaining to each MRMS AF cur- 
rently installed at each medical fa- 
cility individually: admissions, out- 
patient visits and X-ray visits. 

" Based on the CICS transaction IDs 
used by each AF, support groups can 
relate CICS consumption (processor 
service units, memory occupancy and 
I/Os) to the MRMS workload caused 
by each business event: admission, 
outpatient visit and X-ray visit. 

Continuing with the MRMS example, 
the exercise goes like this. 
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© Based on the database design, relate 
the existing records inventory and 
workload-generated DNBUs to disk 
bytes. 
The result is how much capacity is 
consumed by existing MRMS instal- 
lations. 
© The next step is to consider the num- 
ber of DNBUs from existing records 
inventory and workload-generated 
DNBUs and WNBUs for each 
MRMS AF for each planned future 
installation. The various record rooms 
and the corporate statistics office 
supply data by which these estimates 
can be made. Each AF at each facil- 
ity may have a different installation 
date, so that is the way the forecast 
has to be done. 
Finally, based on business forecasts, 
estimate the extra WNBUs and 
DNBUs of the existing MRMS in- 
stallations due to business growth. 

Now three areas are accounted for: the 
existing MRMS installations, future in- 
stallations and business growth. As the 
quantity of NBUs changes, computer re- 
source consumption should change pro- 
portionately. Simple. 

There is one more concept that needs 


to be considered in capacity planning: the Altai Software can help you reach new heights in 


es 


granularity of the implementation sched- "data center automation. 
ule. This is a complicating factor best ex- = Because at Altai, automation is our single focus. 
emplified by PARRS. = All our resources and expertise are devoted to 
When we install PARRS, it is installed = developing the finest data center automation tools 
in a given medical facility department (that = in the world. 
is, an allergy clinic), not in the entire fa- As a result, we offer a clearer understanding of 
cility all at once. (This is largely gov- your needs. Features and utilities that solve real-world 
erned by the speed with which terminals aq data center problems. Products that work with MVS, 
are installed and users are trained.) Each ee VSE, or both. Lower implementation and mainte- 
department sustains a different number of e nance costs. And ongoing support that’s second 
NBUs in the course of its work. Hence " 0 none 


PARRS could be described as a granular 3g orporations worldwide 
installation. For PARRS, our NBU ac- . 15 le 
counting must be extended down to the 
medical department level. (For MRMS, 
the granules for the inpatient record, out- 
patient record and X-ray AFs are the fa- 
cility as a whole since each facility has 
only one inpatient, outpatient and X-ray 
record room.) 

There can, of course, be a different in- 
stallation granule for each AF in an ap- 
plication. Envision an application con- 
taining two AFs, one of which is installed 
a department at a time and one which is 
installed for the entire facility at once. 

To bring all the foregoing together, ob- 
serve that when NBUs for an application 
are counted, we account individually for 
each reporting period, each AF, each 

See Capacity Planning page 95 
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A guide through the maze of 
tools and methods. 


By Robert Lorentzen and Paul Tinnirello 


tions software development, technol- 

ogy moves forward like a speeding 
bullet. An assortment of tools, languages 
and methodologies whizzes by with some 
products on their way to massive popu- 
larity and others en route to extinction. 

For the manager of any sophisticated 
development project, the choice of de- 
velopment tools acts as a bullet as well. 
The right tool for a project can quickly 
hit its intended target and produce a suc- 
cessful system; the wrong one can Stray, 
just as quickly, and become a lethal pro- 
jectile. 

System development managers wonder 
whether to abide by a method with which 
they are familiar (the standard system de- 
velopment life cycle, for example) or to 
test a new technique (prototyping, per- 
haps, or a modified development cycle). 

They worry that the tools they choose 
for a project — the fourth-generation lan- 
guages, application generators, relational 
database management systems and so on 
— will pass into obsolescence before the 
project ends. They wonder, too, whether 
executive management will hold them li- 
able if this worst of ends occurs. 

Such concerns suggest that organiza- 
tions need to adopt procedures for weigh- 
ing each new development tool’s promise 
against each project’s realities and for 
predicting obsolescence, even accepting 
it when necessary. 

The system development manager 
should not attempt to shoulder the entire 


[: the revolutionary world of applica- 


58 


burden himself. Rather, his organization 
should work out a plan that allows a va- 
riety of people to guide the acquisition 
and use of new applications development 
tools. Staff members from the DP de- 
partment should contribute their techni- 
cal knowledge while executives and end 
users lend their business savvy to the 
cause. 

A solid corporate plan for applications 
development includes five major compo- 
nents: 

@ The identification and classification 

of business needs and problems 

™ The formation of a technology task 

group 

@ The decision to use traditional or ex- 

perimental technology 

@ The selection of specific develop- 

ment techniques and tools 

@ The implementation of development 

techniques and tools and the control 
of their use. 

Participants should take care not to bur- 
den the plan with bureaucratic overhead. 
If overcomplication and overmanagement 
seep in, the plan will hinder the devel- 
opment process rather than help it. 


Identifying Business Needs 


Careful scrutiny helps an organization 
determine which of its applications will 
benefit from new development technol- 
ogy and which will not. As such, this first 
stage of the corporate plan is a crucial 
one. 

For help in identifying needs, employ- 


ees who participate in development tool 
acquisition should turn to their organiza- 
tion’s overall business plan. Most organ- 
izations rely on one-year or five-year plans 
to guide their business strategy and most 
plans list the needs and problems the cor- 
poration wants to address. If a software 
development team attacks these specific 
needs and problems, it increases its chance 
of developing successful systems. 

Participants should also learn to distin- 
guish between ongoing business needs and 
dynamic business problems. Typically, an 
organization can rely on traditional tools 
and methodologies to meet its stable needs 
like accounting and payroll. In the same 
vein, more experimental methods may 
provide a firm with its only hope of re- 
sponding to rapid or unexpected change 
in the business climate. 

Clearly, then, if system development 
managers want to find their way through 
the maze of applications development 
tools, they cannot remain ignorant of the 
business functions their applications are 
meant to serve. If the data processing de- 
partment hopes to make wise decisions, 
it cannot keep itself apart from other busi- 
ness groups. 

The corporate plan for tools acquisition 
should help everyone come together be- 
cause it eases the strains that often mark 
relations between DP and other functions. 
Everyone involved with a given applica- 
tion, whether from the business side or 
the technical side, helps determine how 
to proceed. 
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Forming a Technology 
Task Force 


An organization forms a technology task 
force to keep steady watch over advances 
in technology. Managers can assign peo- 
ple to participate either full-time or part- 
time, but the task force should operate 
consistently. 

Task force members perform two major 
functions relative to applications software 
development. First, they investigate and 
evaluate the development tools that the 
organization uses day-to-day, noting those 
that could stand improvement. Second, 
they keep watch on new technology, look- 
ing for tools that might improve targeted 
weaknesses. When they spot a new tool 
that seems well suited to the organiza- 
tion’s business problems, they alert the 
development manager and managers of 
relevant end-user departments. 

Because task force members monitor 
existing operations and upcoming tech- 
nology, they can act decisively when they 
uncover a new product that suits the or- 
ganization’s needs. Their preparations al- 
low the organization to implement any 
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new technology in the least possible time. 

This ability to act quickly helps an or- 
ganization survive in today’s hectic busi- 
ness environment where companies re- 
quire shorter and shorter development 
times. Drawn out development schedules 
are becoming completely unacceptable 
because no company can afford to fall be- 
hind its competition. 

The task force also helps the applica- 
tions development effort by relieving the 
development manager of the responsibil- 
ity for keeping up with every technical 
advance that comes along. 


Deciding Between Traditional 
and Experimental Technology 


In making this decision, the develop- 
ment manager often confronts a dilemma. 
He knows the traditional system devel- 
opment life cycle will work because it has 
worked in the past. He realizes, too, that 
his programmers cannot meet the short 
development schedules required of them 
unless they use newer, quicker, untried 
techniques. 

If an organization has no corporate plan 
for development tool acquisition, the 
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manager finds himself struggling with one 
problem after another. 


@ He considers using rapid prototyping 
methodologies and tools that promise 
drastic cuts in development times but 
he finds that these aids sometimes 
raise end-users’ hopes impossibly 
high. 


@ He then looks into relational data- 
base management systems but the 
debate on that front only adds to his 
confusion. 


@ Next, he tries to find out whether 
procedural languages, fourth-gener- 
ation languages or artificial intelli- 
gence languages serve best for de- 
velopment but all he discovers is 
another lively debate. 


To compound these problems, the man- 
ager must also judge whether the new 
technology is worth the cost and effort its 
adoption will entail and whether prema- 
ture obsolescence will put his final choice 
to shame. Finally, the manager gives up. 

Unable to choose among alternatives, 
he decides just to wait and see if a sure 
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MOST DASD PERFORMANCE SOFTWARE 
TELLS YOU WHAT'S GOING WRONG. 


WE TELL YOU HOW 
TO MAKE IT RIGHT, 


Until now, DASD tuning was a painstaking 
task-requiring hours of statistical analysis just to 
figure out what was wrong. Correcting problems 
often involved guesswork, trial and error and 
just plain luck. DASD ADVISOR from Boole & 
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based DASD tuning tool that eliminates the 
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thing shows up in the near future. More 
often than not, nothing does. 

If, on the other hand, an organization 
identifies its business needs according to 
a corporate plan, the manager’s task be- 
comes relatively easy — especially if he 
can rely on his firm’s end users and tech- 
nology task force members for help. The 
development manager and the other par- 
ticipants should begin by deciding whether 
the application will serve a long-term, 
stable business need or a short-term, dy- 
namic business need. The classification 
will, in turn, help the participants to de- 
termine whether the application will ben- 
efit most from traditional or experimental 
technology. 

Short-term needs justify the use of low- 
cost experimental technology — espe- 
cially personal computer-based develop- 
ment aids — mainly because the risk of 
obsolescence is lower and the conse- 
quences of failure are less dire than they 
would be in more far-reaching applica- 
tions. 

In long-term applications, the risks and 
consequences of choosing experimental 
technology increase and many organiza- 
tions choose to stay with a tried-and-true 
approach. 

Development managers become espe- 
cially apprehensive when they hear re- 
ports that seem to discredit experimental 
tools. 

However fear of failure or obsoles- 
cence is no reason for a firm to shun new 
development technologies altogether. The 
larger the project, the more good a speedy, 
efficient tool can do. Most organizations 
will benefit from a stepping-stone ap- 
proach to long-term projects. 

Under this approach, a company ac- 
quires new tools and techniques one by 
one as a series of short-term solutions to 
a specific long-term business problem. 

When one tool’s usefulness expires, the 
organization re-examines the business 
problem and replaces the obsolete tool 
with a new one that is better suited to 
current business circumstances. 

Companies that are currently switching 
from COBOL code generators to prefor- 
matted screen painters are using the step- 
ping-stone technique to good advantage. 


Selecting Specific Tools 
and Techniques 


Once an organization decides to meet 
one of its business needs with a fourth- 
generation language, a prototyping meth- 
odology or some other type of advanced 
development tool, it needs to choose a 
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specific product from a specific software 
vendor. 

A formal selection process — one that 
works toward a well-defined set of objec- 
tives — helps tremendously at this stage. 

A company should feel free to use any 
common selection method (a weighted, 
unweighted, static or dynamic evaluation; 
a pilot project; or a benchmark) because 
no one method ensures significantly better 
results. However participants in the se- 
lection process need to recognize five im- 
portant points. 

1. Choosing from a few excellent al- 
ternatives is more desirable than choosing 
among a plethora of poor selections. 

The software development marketplace 
remains so competitive that anxious ven- 
dors are releasing some low-quality, un- 
tested products. 

Participants in the selection process 
should identify such products early on and 
eliminate them from consideration. 

2. No vendor deserves blind trust, no 
matter how good that vendor’s reputa- 
tion is. 

User organizations must see that each 
of their prospective vendors defines its 
products clearly and explicitly. 

Many vendors either over-sell their 
products’ capabilities or underestimate 
their clients’ needs although honorable 
vendors recognize when their product is 
inappropriate and objectively recommend 
alternatives. 

3. The longevity of a vendor is as im- 
portant as the viability of that vendor’s 
software tools. 

User organizations should stay alert to 
the need for continuity of support 
throughout their applications’ life cycles. 
If a vendor is not around to service and 
maintain its products, the user organiza- 
tion loses out. 

4. Complete objectivity does not exist; 
everyone holds biases and preferences. 

End users, managers and consultants 
have all been influenced by exposure to 
certain vendors and products and all par- 
ticipants view the selection process from 
different angles. 

If the selection team recognizes its 
members’ biases, the group as a whole 
can work around- them. 

5. Many software selection processes 
fail. This is not because an organization 
follows a bad method but because the 
company fails to define its business prob- 
lem properly or fails to assign trained per- 
sonnel and sufficient time to the process. 

Maintaining the software selection 
process as an integral part of the corporate 


plan provides continuity and a foundation 
for success. 


Implementing Development 
Tools and Controlling Their Use 


Because poor implementation can un- 
dermine the best of plans, this stage is as 
critical as the selection process. As with 
the selection process, success depends on 
incorporating implementation within the 
overall corporate plan. 

Once an organization decides to ac- 
quire a tool, corporate management should 
inform end-user departments of the tool’s 
intended use and invite end users to par- 
ticipate in the upcoming implementation. 

Another key to success lies in under- 
standing the implementation’s purpose. 

That purpose is to use acquired soft- 
ware tools for solving business problems 
and meeting business needs — not to bring 
in new technology so it can proliferate 
beyond control. 

An organization may, for example, ad- 
dress a short-term problem — an unusual 
reporting requirement, perhaps — with a 
tool that the firm fully expects to become 
obsolete within a few years, such as a 
simple microcomputer database program. 

The tool is appropriate to the specific 
business need but its unrestricted use poses 
some risk. If users put the tool to other 
tasks, they may develop an unhealthy de- 
pendence. 

When the tool becomes obsolete and 
the organization wants to drop it, these 
users will stand opposed. 

On the other hand, a tool that an or- 
ganization installs as a solution for a short- 
term problem may sometimes merit long- 
term use. 

This is especially true if the tool grows 
or evolves, and the business need contin- 
ues longer than originally expected. 

Some companies that originally pur- 
chased Lotus Development Corp.’s 1-2-3 
simply for its spreadsheet capabilities have 
discovered, for example, that the prod- 
uct’s macro language supports useful ap- 
plications development as well. 


Keeping Technology in 
Perspective 


Keeping technological advancements in 
perspective with development goals poses 
a real challenge to managers of applica- 
tions development. 

When a new product or new technol- 
ogy gets announced, the manager worries 
that his current development projects may 
be technically obsolete. When his tal- 
ented DP employees leave to work at a 
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firm that implements state-of-the-art tech- 
nology, the manager’s worst fears seem 
realized. Questions of technical obsoles- 
cence become a burden and a nightmare. 

These reactions are stronger than the 
situation merits. True, no manager wants 
to develop a corporate system that is ob- 
solete before its implementation, but many 
managers simply do not keep their fear of 
technological advancements in perspec- 
tive. Some managers go so far as to de- 
velop an obsolescence syndrome, a fear 
that their skills are no longer current. This 
fear, in turn, leads a manager to self doubt, 
which helps no one — not the manager, 
not his firm. 

Systems development managers who 
find themselves doubting their abilities 
should take a lesson from their counter- 
parts in software maintenance. 

Managers of software maintenance 
functions often shoulder accusations of not 
being technically current. But these sea- 
soned professionals shrug off their de- 
tractors’ comments. Maintenance man- 
agers realize that most of today’s hot new 
software will lose its popularity as time 
passes. They know, too, that their talents 
will never lie idle; every development tool 
will require their support sometime down 
the road. 

Applications development managers 
must recognize one double-edged fact: not 
all technology is obsolete, yet any tech- 
nology faces a chance of obsolescence. If 
a development manager anticipates each 
application’s life expectancy and imple- 
ments new or old technology according to 
the relative risks, he can do little more 
and should try to relax. 

Sometimes quantum leaps in technol- 
ogy such as the emergence of microcom- 
puter spreadsheet software warrant a re- 
evaluation of system development goals. 

Managers should keep themselves open 
to the possibility of redirecting a project 
in those cases. It is not wise, however, to 
impede system development projects each 
time development technology advances. 

In addition to keeping a personal per- 
spective on technology, the development 
manager should also help end users and 
corporate managers balance the promises 
and risks of technological development. 

End users are no longer naive about 
computer technology. They can see the 
productivity that is possible with spread- 
sheet packages and menu-driven micro- 
computer databases and they may have 
used fourth-generation languages in a pre- 
vious job. 

Inevitably, they hold opinions about 
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Identify and Classify Business Needs 
An organization’s overall business plan generally lists specific needs. Careful 
scrutiny of these needs helps determine which ones will benefit from new devel- 
opment tools and techniques and which ones will not. 
Form a Technology Task Force 
A group of people dedicated to watching for new developments can help an 


organization act quickly and decisively when a tool that matches a business need 
comes to market. 
Decide Between Traditional and Experimental Technology 

For short-term projects, experimental tools post little risk if they are inexpensive 
and can be implemented quickly. For long-term projects, experimental tools carry 
the risk of obsolescence, but that risk diminishes if an organization implements 
them as a series of short-term solutions. 

Select Specific Tools 

Any well-directed selection process works as well as any other, as long as man- 
agers work toward solving business needs and keep the process in line with the 
overall corporate plan. 

Implement Tools and Control Their Use 
The purpose of implementation is to use acquired software tools for solving 

business problems and meeting business needs — not to allow new technology to 


proliferate beyond control. 


software tools and vendors. Likewise, 
most upper managers have worked with 
computer-based systems — some suc- 
cesses and some failures. They therefore 
harbor strong biases of their own. 

These knowledgeable people outside of 
the DP community are privy to announce- 
ments of fourth-generation languages and 
other tools, that raise their expectations 
— sometimes impossibly high. Users and 
managers then pressure the system devel- 
opment manager to act. 

When questions of control arise, these 
users and managers no longer give in to 
pressures from the DP organization. 
Rather, they take an active role in and 
responsibility for the systems. And that is 
as it should be. 

The development manager should cau- 
tion corporate executives about premature 
use of new technology but should remain 
flexible in his convictions. When a new 
technology purports to provide greater 
power and control for end users, the sys- 
tem development manager may have to 
compromise so as not to alienate these 
important constituents. 

Quite clearly, problems like end-user 
autonomy and premature obsolescence 
make system development a complex task, 
despite the common belief to the contrary 
that the task gets easier as technology ad- 
vances. Compared with the relatively 
simple world of 10 or 15 years ago, to- 
day’s development environment is terri- 
bly complex. 


Development managers face advanced 
business requirements and must choose 
among a variety of development method- 
ologies and a vast set of tools. 

The vendors that develop new products 
deserve commendation for their contri- 
butions. However the technical and busi- 
ness communities cannot continue to 
praise blindly each new development. 
User organizations and their vendors need 
to address the practical problems that a 
company encounters as it applies new tools 
to the development of business systems. 

The impact of new technology is felt 
throughout the entire business and re- 
sponsibility for coping with it must spread 
throughout the company as well with cor- 
porate managers, end users and applica- 
tions development managers all playing a 
part. Recognizing this is the first step to- 
ward strengthening the use of new prod- 
ucts and developments. Finding new 
techniques, such as the corporate plan for 
new technology, is the next step. = 
Copyright 1986 by CW Publishing, Inc., 


Framingham, MA 01701. 
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At HOTSITE’s recovery 
facility in Cary, NC, the 
staff loads its client’ s 

operating system so that 
it will be up and running >=, 
when the client arrives to B& 
load the application. 


hile terrorist bomb threats were 
unlikely, Alan Tarbox worried 
about floods and fires. As pres- 


ident of the data processing subsidiary of 
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Dilemma 


By Beth Ellyn Rosenthal 


a $1.8 billion bank in Nashua, NH, Tar- 
box is responsible for the smooth han- 
dling of data regardless of the circum- 
stances. Like the rough and tough riders 


anking Consortium Solves 


of the Pony Express, the members of In- 
dian Head Data Services had to proof 
checks and handle exceptions even if 
someone did a good job of pulling the 
plug. 

Tarbox realized Indian Head Banks, 
Inc. needed a backup processing site for 
disaster recovery. “‘Every financial insti- 
tution has a responsibility to provide on- 
going service to the customer even when 
the computers are destroyed by fire and 
flood. We cannot afford to be out of op- 
eration for five days,’ Tarbox explains. 

What is at stake is the customer’s con- 
summate belief in the integrity and via- 
bility of the bank. ‘‘Banking is based on 
the confidence your customers have in 
you. Much of that confidence stems from 
your continued service,’ Tarbox points 
out. 

On the financial side, banks cannot af- 
ford to take the day off. They immedi- 
ately lose interest on the available funds 
they were not able to process. Also, they 
can fall out of compliance with federal 
banking rules, including the new Expe- 
dited Funds Availability Act. Finally, 
stockholders are worried about the secu- 
rity of their investment. Disaster recovery 
is a key component in that protection. 

However, Indian Head, a member of 
the Fleet/Norstar Financial Group of 
Providence, RI could not afford the cap- 
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ital costs of duplicating its own equip- 
ment elswhere to create a mirror image 
processing center to be used only in time 
of trial. 

“‘The costs are significant,’ says Tar- 
box, estimating a backup site would cost 
the bank about 75 percent of its data pro- 
cessing equipment costs. “‘First, we had 
to rent space that is available 24-hours-a- 
day. Then we needed a new computer sys- 
tem that we could switch on if something 
went wrong. Add to that the maintenance 


Disaster Recovery 


costs and we just couldn’t do this on our 
own,’ he explains. 

So Indian Head, along with eight other 
banks in northern New England and 
Maine, formed a consortium to share the 
costs of establishing and running a backup 
site. The consortium, formed in 1985, was 
christened the Northern New England 
Backup Services Corporation. 

The consortium rented space in the 
Federal Reserve Bank of Boston’s re- 
gional check processing center in Lewis- 
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that gets. burned. 
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ton, ME. It purchased an IBM 4341, a 
system common to all members. Each 
bank then solicited employees to staff the 
site on a voluntary basis. 

The data processing chieftains breathed 
a collective sigh of relief when the lights 
on the backup computers started to glow. 
Each member had the reassurance the bank 
could continue processing in the midst of 
a disaster at a cost the financial institution 
could afford. 

However, the calm turned out to be 
short-lived. 

The Boston boom spilled over into New 
England where banks began to grow at an 
exponential rate. Like the piglets in 
George Orwell’s *‘Animal Farm,’’ some 
banks grew faster than others. They ac- 
quired ravenous appetities and began 
swallowing the little fish. On the other 
hand, some members, including Indian 
Head, were acquired by area giants. 

Suddenly each bank had different needs 
and conflicting requirements. The success 
of the region was tearing asunder the 
carefully crafted consortium. ‘‘The needs 
of our members changed so dramatically 
we found some members could not live 
with our existing system,’ Tarbox re- 
members. 

Two years after its inception, the con- 
sortium faced a dilemma. Facing surging 
capital outlays to update and upgrade its 
center, it either had to purchase more 
equipment, disband or seek outside help. 
Since the nine banks had worked so well 
together, they searched for a vendor who 
could service their now heterogeneous 
needs. If possible, the bankers wanted to 
keep their monthly membership dues in 
the same range. 

In the late fall of 1987, the consortium 
signed a five-year contract with HOT- 
SITE, a Cary, NC vendor. The vendor 
agreed to open a new site for the consor- 
tium in Tewksbury, MA if the company 
could solicit other clients as well. 

HOTSITE, that specializes in provid- 
ing disaster recovery backup services for 
mid-range IBM mainframes, moved the 
consortium’s 4341 to Tewksbury, then 
added another larger CPU and more than 
doubled the consortium’s disk space. 
‘‘Our CPU capacity increased 250 per- 
cent. HOTSITE greatly expanded our data 
processing facilities,’ Tarbox adds. 

These amplified capabilities have al- 
lowed the member banks to add new serv- 
ices that the understaffed, overworked 
consortium center could not handle. For 
example, while all the member banks had 
item capture and batch processing well 
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covered, none were backing up the on- 
line transactions of their branches. Now 
HOTSITE is also doing that for them. 
Tarbox was also gratified that HOT- 
SITE supplied trained personnel to man 
the center round the clock. ‘‘They have 
15 people there at all times monitoring 
our accounts. Before, Federal Reserve 
employees were there all night, but it was 
not their job to service us. We provided 
our own staffing,” Tarbox points out. 


Disaster Recovery 


The volunteer system was not the op- 
timal staffing approach, points out John 
Butch, division manager for HOTSITE. 
‘‘The volunteers made their full-time job 
their first priority. Finally it became a bur- 
den to manage the facility,’ he com- 
ments. A permanent staff gave HOTSITE 
the manpower and the technical support 
to perform more extensive disaster testing 
that the consortium’s employees had nei- 
ther the time nor the training to do. 
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Finally, HOTSITE also owns a relo- 
catable shell facility that any member of 
the consortium can use after a natural or 
manmade disaster. The modular shell 
snaps together like Lego toys to form a 
3,500 square-foot computer room with the 
requisite raised floor. ‘‘In less than two 
weeks the consortium had a new com- 
puter center,’ Butch points out. 

After HOTSITE assembles the shell in 
the bank’s parking lot, communications 
lines are tied in. The bank buys its new 
equipment that HOTSITE installs in the 
portable center. When the permanent fa- 
cility is rebuilt, HOTSITE moves the 
computers to their real home. 

Butch says relocatable shells are criti- 
cal when disaster really strikes. Even the 
swiftest construction foreman requires a 
minimum of three months to rebuild a 
bank’s computer center. That means for 
at least 90 days, the data processing staff 
must relocate to the backup site that can 
easily be a two-to five-hour drive until the 
dust settles back home. 

“It doesn’t take long for an employee 
to be away from home before becoming 
disgruntled. Relocatable shells allow the 
bank to minimize the inconvenience,’’ 
notes the HOTSITE executive. 

So how much does this fortified service 
cost? ‘‘We were able to put together 
backup services for the consortium with 
enhanced equipment, on-site technical as- 
sistance and full time management for no 
more dollars out the door,’ Butch points 
out. 

Tarbox adds that each member contin- 
ues to pay his current assessment, a price 
that will remain fixed until 1990. There- 
after, the consortium dissolves, allowing 
each financial institution to negotiate its 
own rates with the vendor. 

HOTSITE is happy it can help bankers 
like these sleep well at night. ‘‘Com- 
puters are pervasive in banking. Many 
banks open new accounts through a ter- 
minal. ATMs are run by computer. The 
commercial and installment loan depart- 
ments need access to the data bank. I don’t 
know any bank today that processes a 
check without a computer. HOTSITE is 
their best insurance policy,’ concludes 
Butch. = 


ABOUT THE AUTHOR 


Beth Ellyn Rosenthal is the foun- 
der of the Writers Block, a Texas 
writers’ syndicate. She is the syndi- 
cate’s banking and technology spe- 
cialist. 


February 1989 


For CICS/VSAM Data Recovery, 
Integrity Solutions 
is the Global Choice. 


These leading IBM mainframe companies trust the 
integrity of their corporate data to Integrity Solutions. 
They selected Integrity Solutions’ DATA RECOVERY 

SYSTEM (DRS) because it provides the most 
comprehensive forward and backward recovery for files 
accessed by CICS/VS and VSAM batch processing. 


Integrity Solutions introduced DRS more than 8 years 
ago, and with over 1000 product installations worldwide, 
Integrity Solutions will continue setting the data integrity 

standard. By providing leading-edge products and the 

highest level of support....to serve your data 
recovery needs now and in the future. 


Guided by what users say they need next, 
Integrity Solutions is setting the data integrity standard 
for the emerging electronic vaulting 
and mirror processing marketplace as well. 


The DATA RECOVERY SYSTEM from Integrity 
Solutions, because your data is worth it. 


= Integrity 
= : Solutions, Inc. 


1-800-289-9900 
1-303-794-5505 


Fee rien va “eh, 2. 
_ Integrity Solutions. . 
__- Data Integrity Stz 
te. ; is SS 
CIRCLE #43 on Reader Service Care 
é + . 7 ; : a 


Capaci 
Sarees 


The capacity surface offers the 
analyst a vehicle for 
communicating large quantities 
of complex modeling results to 


erhaps the most difficult problem 
P= by capacity planners and per- 

formance analysts is not how to 
measure, predict or improve the perform- 
ance of their systems but how to effec- 
tively convey their results to executives. 
An interesting paradox is presented to the 
analyst who is immersed in detailed data 
and the decision maker who wants a quick 
summarized view of daily performance or 
the capacity of a system. On one hand, 
the analyst is concerned that responding 
with too little information will result in 
misconceptions about the characteristics 
of the system. On the other hand the de- 
cision maker typically requests a one page 
summary that will allow him to under- 
stand his alternatives and reach valid con- 
clusions. 

In an effort to achieve a compromise, 
many analysts have attempted to provide 
abbreviated report formats, perhaps just a 
few pages, to address the decision mak- 
er’s needs. These analysts are often hor- 
tified when the decision makers net out 
their presentations to a single number that 


the analyst feels is invalid. One trait of 


human nature is that a person who wants 
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decision makers. 


By H. Pat Artis 


to simplify a decision will do so with or 
without the help of others involved in the 
process. For decision makers, this reac- 
tion is not an attempt to trivialize a prob- 
lem but rather an attempt to fit the deci- 
sion process within the time available in 
their schedules. 

Historically, a variety of numerical and 
graphic presentations have been em- 
ployed to convey performance and capac- 
ity data to decision makers. For example, 
indices have been used to rank service 
level and utilization measurements to re- 
lieve the recipients of the reports of the 
need not to remember what values are 
good and bad. While such approaches can 
convey a tremendous quantity of data, the 
recipients are left to interpret the relation- 
ship between the indices themselves. A 
variety of graphic presentation formats 
have also been investigated. 

Perhaps the most commonly used 
graphic format is shown in Figure |. This 
figure presents a history of CPU utiliza- 
tion and a forecast of expected future val- 
ues of the processor’s utilization. Using 
a rule of thumb guideline for target CPU 
utilization, the capacity of the system is 


defined as the point at which the average 
CPU utilization during the peak hour ex- 
ceeds the selected target value. In the ex- 
ample shown in Figure 1, 85 percent was 
chosen as the target maximum value of 
CPU utilization that could be realized 
while still delivering acceptable service 
levels to the system’s users. 

It is important to realize presenting uti- 
lizations as a primary measure of capacity 
obfuscates the real issue of capacity plan- 
ning, in other words service levels. This 
often leaves the decision makers ques- 
tioning why they cannot realize 100 per- 
cent of the apparent value of their invest- 
ment. Moreover, the recipients of the 
report were very likely to simplify the en- 
tire decision process by concluding that 
their system’s capacity is the specified 
target utilization whatever that meant in 
terms of their workload or service levels. 

When analytic queueing models were 
introduced in the late 1970s, they pro- 
vided the capacity planner with powerful 
tools for relating workload arrival rates, 
utilizations and service levels. Depending 
on your perspective, the wealth of de- 
tailed data that these models provided the 
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analyst either revolutionized or further 
complicated the capacity planning proc- 
ess. From the analyst’s perspective, the 
models provided them with a much more 
detailed understanding of the interactions 
and service levels of the system’s work- 
loads. From the decision maker’s per- 
spective, the quantity of data, however 
useful, that the capacity planner wanted 
to convey to them markedly increased. 
Not withstanding these issues, the use of 
analytic models focused both the analysts 
and decision makers on service level re- 
lated measures of capacity for the first 
time. 

Perhaps the most common graphic pre- 
sentation format used to convey the re- 
sults of the analytic models is shown in 
Figure 2. The graph shown in the figure 
relates the response time of the system’s 
critical workload to the transaction vol- 
ume with the limit line being defined by 
the service objective for the application 

. assuming a given background level 
of other workloads. One unfortunate 
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Capacity Surfaces 


characteristic of this format is that it in- 
vites the recipient to reach a potentially 
invalid conclusion. For the system por- 
trayed in Figure 2, the decision maker is 
invited to conclude that a throughput of 
eight transactions per second can be 
achieved while still meeting the service 
objective of one second. This conclusion 
is likely to be invalid long term since the 
model assumed a constant value for the 
background workloads that are also likely 
to grow in the future. 

From the analyst’s perspective, such 
problems illustrate the pitfalls of the ner 
it out in one page school of thought. Sim- 
ply described, there are far too many im- 
portant variables to allow meaningful re- 
sults to be summarized onto a single page. 
Further complicating the entire manage- 
ment process is the fact that the one page 
daily performance summary often bears 
little similarity to the reports provided 
during the capacity planning process. 

Recently, during a conversation with a 
corporate executive, I had used these ar- 
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guments in an attempt to explain the lim- 
itations and pitfalls of the one page sum- 
mary to the client. Unhappy with the 
explanation, the client rephrased the 
question in a manner that provided me 
with a new insight into the problem. What 
the client said was, ‘*‘What I really want 
to know is how close I am to the edge 
and how far I can go before I fall off?’’ 

The question suddenly implied that the 
system’s capacity was better represented 
by the concept of a surface than by ab- 
solute values of arrival rates or utiliza- 
tions. Since a surface is defined by thou- 
sands of points, it provides a single page 
format that can incorporate the wealth of 
data identified by the capacity planner 
while still realizing the decision maker’s 
objective of brevity. 

To paraphrase an observation made by 
Alan Kay, widely regarded as one of the 
true visionaries of personal computing and 
an Apple Fellow, ‘‘most corporate exec- 
utives, although they’ve never really 
thought about it, would prefer to have a 
model of their system’s performance with 
which they can visualize its response to a 
variety of situations’’ rather than rely on 
records to see how changes in the past 
have affected the service levels delivered 
to their users. The capacity surface offers 
an approach to addressing this require- 
ment. The remainder of this article de- 
scribes how capacity surfaces are gener- 
ated and will show how they can be used 
to address the daily performance report- 
ing, capacity forecasts and analyze the 
benefits of alternative hardware upgrades. 


Building A Capacity Surface 


To illustrate the development of a ca- 
pacity surface, it is useful to introduce a 
simple queueing model. Figure 3 depicts 
a simple two workload model that de- 
scribes the performance of a system com- 
prised of a CPU and two disk drives. 
While this model is far simpler than the 
commercial tools that are used to analyze 
actual MVS environments, it will serve 
the purpose of demonstrating how capac- 
ity surfaces are developed. By varying the 
arrival rates of the two workloads, the 
performance and utilization levels of the 
system can be predicted for any environ- 
ment. For example, if a background ar- 
rival rate of workload two was assumed 
to be three transactions per second, the 
curve previously shown in Figure 2 would 
be produced when the arrival rate of 
workload was varied from one to eight 
transactions per second. 
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Capacity Surfaces 


If the model were used to calculate the F I G U RE 4 


response time of workload one for all pos- 
sible combinations of the arrival rates of r . 
the two workloads, then the three dimen- Workload 1 Response Time Ribbons 
sional plot shown in Figure 4 could be Workload 1 Arrival Rate, Trans/Sec 
developed using the arrival rates and pre- 

dicted response times. In effect, the rib- 

bons shown in the figure represent the Workload 1 
family of response time curves from which Response 
Figure 2 was selected. An alternative rep- Time 
resentation of the family of curves shown 

in the figure is the capacity surface shown 

in Figure 5. The capacity surface conveys 

the predicted response time of the system 

over all possible combinations of arrival Workload 2 
rate values. The broad sloping surface that Arrival Rate, 
begins in the lower left hand side of the Trans/Sec 
figure represents the range over which the 

system can deliver acceptable service lev- 

els. The ledge at the upper right hand side 


of the slope represents arrival rate com- 
was FIGURE 5 | binations. Although they do not saturate 
the system, they result in response times 
in excess of the one second target for 
Capacity Surface system. Finally, the void in the upper 
Workload 1 Arrival Rate, Trans/Sec right hand side of the figure represents 
arrival rate combinations that saturate the 
system. 
The resulting capacity surface provides 
a single page reporting format that can 
convey tremendous quantities of data to 
the decision maker. Using the capacity 
surface, meaningful answers can be pro- 
vided to the question how close am I to 
the edge and how far can I go before | 
fall off? 


Daily Performance Reporting 


Workload 1 
Response 
Time 


Workload 2 
Arrival Rate, 
Trans/Sec 


Once a capacity surface has been de- 
veloped for a system, the report can be 
used as a medium for daily performance 
reporting. The graph in Figure 6 depicts 

the performance of the system for a given 
FlGURE 6 day. Since most real world systems have 
more than one competing workload, the 
Daily Performance Reporting Y-axis of the graph shown in Figure 6 


Critical Workload Arrival Rate, Trans/Sec expmeace tie pementage of CPU uliliza- 
tion represented by all of the competing 


workloads, rather than the arrival rate for 
any one of them. The data point shown 
on the surface represents the performance 
observed on the prior day. The benefit of 
the capacity surface for daily performance 
reporting is that it conveys far more than 
just how the system performed; it pro- 
vides the recipient an expectation of 
whether or not the service level can be 
maintained in the future. For example, the 
data point in the figure appears in the broad 
and almost flat plane of response time in 
the lower left hand corner of the figure. 
Hence, it is reasonable to infer that the 
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system’s performance would be main- 
tained even if substantial changes oc- 
curred in the users’ demand on the sys- 
tem. However, if the data point appeared 
near the ledge on the steep part of the 
surface, then it would be reasonable to 
infer that future performance levels might 
be erratic or unacceptable. 


Capacity Forecasts 


Like performance prediction, workload 
forecasting involves a tremendous quan- 
tity of detailed data. While a single work- 
load forecast may suit the needs of a 
simple environment, typical workload 
forecasts are the result of independently 
analyzing the behavior of perhaps a dozen 
primary applications. Once this data has 
been collected and analyzed, the capacity 
surface provides a medium for commu- 
nicating it to the decision maker. 

Figure 7 provides a workload and serv- 
ice level forecast using the capacity sur- 
face as a reporting medium. The data 
points connected by a solid line represent 
the historical behavior of the system and 
the projected load and service levels for 
the next three quarters are denoted by dis- 
crete points. As can be seen in the figure, 
response time will degrade over the next 
two quarters. Moreover, the demand fore- 
cast for the third quarter does not repre- 
sent a point on the capacity surface or 
even a point.on the ledge where the sys- 
tem could serve the expected workload at 
a degraded level of service. Hence, the 
third point conveys that the system will 
be completely saturated in the third quarter 
of 1989 and that the current configuration 
is incapable of supporting the anticipated 
load at any level of service. Once the ex- 
haust point of the system has been iden- 
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Demand and Service Level Forecast 
Critical Workload Arrival Rate, Trans/Sec 


tified, the next natural question is what 
kind of upgrade will be required to serve 
the anticipated load? 


Evaluating Upgrade Alternatives 


Another potential application of the ca- 
pacity surface is the evaluation of upgrade 
alternatives for a system. For example, 
what would be the impact on the system 
of replacing the system’s CPU with one 
that is one third faster? To answer this 
question, the transaction CPU times pre- 
viously shown in Figure 3 would be re- 
duced by one third and then the response 
time values used to develop the capacity 
surface would be recalculated. Figure 8 
shows the capacity surface that would re- 
sult if the CPU were upgraded. As can be 
seen in the figure, upgrading the CPU 
substantially expands the range of arrival 
rates over which the system can meet its 
response time objectives. 
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In the event that multiple upgrade al- 
ternatives were being considered, a ca- 
pacity surface could be developed to fa- 
cilitate comparisons of the alternative 
configurations. The principal benefit of the 
capacity surface in this process is that it 
focuses decision makers on what a poten- 
tial configuration can do for their systems 
rather than abstract comparisons of MIPS 
or device characteristics that may or may 
not be exploitable by the system’s work- 
load. 


Remarks 


While it is impossible to envision that 
any single page reporting format will ever 
meet all of the requirements of the ana- 
lyst, the capacity surface offers the ana- 
lyst a vehicle for communicating large 
quantities of complex modeling results to 
decision makers. Moreover, it provides a 
common report format for addressing daily 
performance reporting, capacity forecasts 
and the evaluation of alternatives in a 
complex environment. = 
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By Eric L. Vaughan 


of a busy four-way intersection. A 

traffic cop is directing the flow of 
traffic in an effort to move as many cars 
through the intersection as possible. He 
has established his own priority scheme, 
albeit random, in order to determine which 
lane of cars to begin moving first. One of 
the lanes tends to build up faster than the 
others so he always attempts to allow this 
lane to move first. 

The traffic cop selects the high priority 
lane and motions for the cars to start mov- 
ing. As the sixth car passes, he hears an 
ambulance coming from the opposite di- 
rection. The ambulance creeps around the 
now halted traffic and immediately pro- 
ceeds through the intersection. Once 
again, the traffic cop begins the flow of 
traffic by allowing the priority lane to 


[ is five p.m. on Friday in the middle 
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move. When this lane is empty, he turns 
to the lane next in priority in order to 
begin ‘‘dispatching’’ cars. However, he 
notices that the last car from the first lane 
remains slightly in the intersection, 
blocking the path of the second lane. Be- 
cause of this he decides to select the next 
lane that has a clear path. Cars from the 
third lane begin to move through the in- 
tersection freely until the traffic cop hears 
the urgent blare of someone’s horn. He 
immediately stops the third lane and dis- 
covers that the horn-blower, waiting on a 
path through the intersection, is in the 
second lane that is now clear. He notices, 
however, that cars have again built up in 
the high priority lane so he allows the first 
lane to move. The first lane empties and 
the traffic cop begins to move cars out of 
the second lane, then the third lane. Fi- 


nally, he turns to the fourth lane and mo- 
tions for the cars to begin moving. One 
of the cars stalls out and now the fourth 
lane is waiting so the car can be removed. 
This move optimizes the entire intersec- 
tion because each of the other three lanes 
has built up a line of cars again. The traffic 
cop starts moving the high priority lane 
but notices the mayor’s car at the head of 
lane two. Being a model citizen as well 
as a member of the same political party, 
he immediately halts the first intersec- 
tion to allow only the mayor’s car clear 
passage. 


Traffic Cop? 


From reading the preceding scenario, it 
is obvious the traffic cop may not be qual- 
ified to move traffic. However, the sce- 
nario illustrates the fundamentals of the 
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VPS 
Support 


Of Network 
Printers On 
MVS Is A 
Complex Task 
Made Simple. 


VPS has been used to replace other products, 
such as: IBM's 328x/ADMPRINT/DSPrint, CICS 
supported printing, SASWTR®, RJE and many 
others, with a single task to drive all your 3270 family printers directly from the JES 
spool (including cross domain VTAM printers). 


1400 Sites use VPS as their shop 
standard 3270 family printer driver. 


e Printers supported include the full array of 3174/3274 
attached printers, including IPDS support for 42x4's, HP and 
Xerox lasers, plotters and PC printers. 


VPS runs as a VTAM application. NO system modification. 
NO JES maintainance. 


Automatic forms control, full FCB support, dial-up PC 
printer, printer pooling and “hot" printers are all supported. 


Full screen “ISPF-like” command interface for CICS, TSO 
and ROSCOE permit end-user control of printers with totally 
menu driven command entry. 


CALL or write for more information, or to arrange 
for a free TRIAL — ATTN: Marketing Dept. 


Specializing in Computer Systems Software 
2387 West Monroe ® Springfield, Illinois 62704 © (217) 793-3800 
Telex (510) 60-00675 


" Trademark of SAS Institute, Inc., Cary, NC. 
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VSE dispatcher and scheduling system. 
The dispatch mechanism resembles the 
traffic cop deciding which task in the sys- 
tem deserves its resources, yet it does so 
without any political prejudice in the de- 
cision-making process unlike the traffic 
cop in the example. 

Although there exists a large number 
of external modules and programs within 
the system, the heart of the VSE operat- 
ing system is known as the supervisor. 
The supervisor is a large Assembler lan- 
guage program shipped by IBM in source 
code format containing several macros (for 
example, SGSCHED, SGSTAR and so 
on). A few default ‘‘sups’’ (pronounced 
‘‘soups’’!) are sent with the product in- 
stall for VSE and in many cases you may 
not need to assemble one. For purposes 
of VSE problem debugging as well as for 
this article’s focus, it may be enjoyable 
to reference a listing. 

On an IBM System/370 architecture 
CPU, the system is known as an “‘inter- 
rupt-driven’’ system. There are five classes 
of interrupts including Input/Output (I/O), 
program check,  ‘‘Supervisor-Calls”’ 
(SVCs) and external and machine check. 
Both the SVC and program check inter- 
rupts are caused by the execution and fail- 
ure thereof, respectively, of an instruc- 
tion. The VSE supervisor is comprised of 
routines for all five classes of interrupts, 
dubbed ‘‘interrupt handlers,’’ and the task 
scheduling system called the ‘‘dis- 
patcher.’’ In our last peek ‘‘under VSE’s 
covers’’ in the November/December 1988 
MAINFRAME JOURNAL, the major 
control block structure of the VSE system 
was discussed in detail. In this article, the 
supervisor’s interrupt and _ scheduling 
mechanism will be explored in depth. 


Who’s On First? 


Fortunately, the supervisor’s schedul- 
ing technique is not subject to the kind of 
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Storage Locations Used for Interrupt Processing 


Old PSW 
Address 


External X'18’ 
SVC X'20' 
Program Ck. X'28' 
Machine Ck. X'30’ 
1/0 X'38’ 


Interrupt 
Type 


confusion that the Abbot and Costello 
routine exemplified. Its role is to allow 
the highest priority task in the system that 
is ready to run to use the CPU. The in- 
terrupt process is an asynchronous one 
however. That is to say an interrupt is not 
scheduled, it simply ‘‘happens’’ as a re- 
sult of an event. An example is the com- 
pletion of an I/O request. 

When a program is executing and an 
interrupt occurs, the CPU’s microcode 
stores the current Program Status Word 


In all cases, final exit 
of the interrupt 
handlers is through 
the dispatcher or 
task selection routine. 


(PSW) and interrupt information in a fixed 
location in low storage. Depending on the 
class of interrupt, a new PSW is loaded 
from low storage for the appropriate rou- 
tine to handle the interrupt (see Figure 1). 
The second word or address portion of the 
PSW will point directly into the interrupt 
handler routine in the supervisor. (A note 
of caution: several OEM vendors rou- 
tinely modify the new PSWs as a way of 
‘“‘hooking’’ the system.) The new PSW 
that is loaded has all interrupt mask bits 
off in order to single thread the interrupt 
routine. 

The interrupt routines store registers 
nine through 13 in a field in low core 
called ERA so they may establish ad- 
dressability. At this point a routine is ex- 
ecuted called GENeral ENTry (GE- 
NENT) to save the interrupted PSW and 
registers that were in effect prior to the 
interrupt into the task’s save area located 
off of the TCB. How did we know which 
TCB to address? Remember, in the Fixed 
Control Area the major task control blocks 


New PSW 
Address 


X'58' 
X'60' 
X’68' 
X'70' 
X'78' 


Interrupt 
Information 


X'86-87' (external code) 
X’88-8B’ (SVC code) 
X’8C-8F’ (PgmCk code) 
X'E8-EF’ (MCK code) 
X’BA-BB’ (1/0 address) 


are anchored here for the task currently 
“‘dispatched’’ (see Figure 2). Thus we 
load the pointer to the TCB from low core 
address X'260' and address the save area 
at TCB +X’0C’. Then the appropriate 
interrupt routine handles its business based 
on the interrupt information. Following is 
a brief look at two of the most common 
interrupt routines. 

In the event of an SVC interrupt, the 
supervisor first checks for a ‘‘fast-path’’ 
SVC (SVC107). Then if it is a fast-path 
SVC, the supervisor branches directly to 
its service routine. Otherwise, it takes the 
interrupt code at hex location X’88' (see 
Figure 1) and uses that code as a “‘vec- 
tor’’ off of the SVC table (SVCTAB) to 
locate a service routine. SVCs are re- 
quests from a task in the system asking 
the supervisor to perform services such as 
start an I/O request (EXCP macro for 
SVCO00) or get the time of day (GETIME 
macro for SVC34). If the SVC routine 
frees a resource or changes the calling 
task’s dispatch status, the SVC handler 
exits to the task selection routine in the 
dispatcher. Otherwise, a special exit is 


Fixed Control Area (PSA) 


Low Core 
Address (HEX) Description 


240-241 Flags 
Routine Indentifier (RID) 
Current Time Pointer 
Address of PIB2TAB 
Address of System PCB 
Address of SCB Address Table 
Address of Current SCB 
Partition Selection String (PSS) 
Pointer to Current TCB 
Pointer to Current TIB 
Pointer to Current PIB 
Pointer to Current PCB 
Debug Header Address 
Debug Parameter Address 
Address of First Level Interrupt Handler 
Address of Dispatcher 
ERA Save Area 
Address of TIBATAB-4 
Address of PCB Address Table 
Number of Page Frames Available 
Minimum Number of Pages Not Fixed 
Save Field for RID 
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taken to the label SAMETASK in the dis- 
patcher in order to simply re-dispatch the 
calling task. 

An I/O interrupt is processed based on 
the device address that has been stored at 
low core address X’BA’ (see Figure 1). 
The device address is used to scan the 
PUB table and set up the proper address- 
ing to the control blocks, that is the 
CHANQ, PIB, TIB, TCB and PCB. The 
Channel Status Word (CSW) that was also 
stored at low core address X'40-47’' at the 
time of the interrupt is examined to eval- 
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uate the status of the interrupt. If final 
status is indicated for a specific I/O re- 
quest, the CCB is posted complete, the 
I/O is dequeued from the CHANQ and 
the task that had requested the I/O is 
posted ‘‘ready-to-run.’’ At this point, the 
interrupt handler branches to the channel 
scheduler whose responsibility is to scan 
the PUB table for the next device on the 
interrupting channel with an outstanding 
I/O request and to initiate a Start-I/O (SIO) 
for that device. 


And now, one lucky TASK will 
be selected to... 


In all cases, final exit of the interrupt 
handlers or any other supervisor service 
routine is through the dispatcher or task 
selection routine. This is the heart of the 
selection logic in the supervisor and its 
responsibility is to determine the next task 
to use the CPU’s resources. 

The control blocks described in the pre- 
vious article are used in depth in this 
process. For speed considerations, this 
process uses a ‘‘top-down’’ approach. 
That is to say, the first available partition 
is selected to run, if any, and then the task 
within the partition is selected. The code 


Problem: BATCH and Application programs 
do not fully utilize VSAM buffers. 


Solution:Bim-BUFF—Dynamic VSAM 
Buffer Management System. 


For faster VSAM processing immediately, use BIM-BUFF 


BIM-BUFF is a product which is designed to significantly increase the performance of VSAM 
in every DOS/VSE installation. It does this in a way which is transparent to the programs 
involved, does not alter any VSAM files, and does not make any modifications to VSAM 
itself. While each installation is different, experience with some DOS/VSE installations has 
shown potential savings to be astounding. The following savings have been achieved in 


benchmarks of real life applications: 


Typical sequential access 
Typical random access 
Clustered random access 


Physical I/Os 


Elapsed Time 
10-50% 
40-60% 

95% 


33% 
25-50% 
99% 


In fact, the performance benefits can be so significant, that it may be possible in some cases 
to defer the purchase of new hardware. Perhaps best of all, these savings can be realized 
almost immediately. BIM-BUFF installs in minutes with no need to change any existing files, 


programs or JCL. 


BIM-BUFF is priced at $2,400 for a permanent license, $1,200 on an annual lease or $120 


on a monthly rental. 


B | Moyle Associates, Inc. has been dedicated to providing cost effective software solutions, 
which improve system performance and user productivity, for 10 years. For more information 
on BIM-BUFF, or any of our other quality software products and services call Jim Kingsbury 


at 612-933-2885 today. 
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B | MOYLE ASSOCIATES, INC. 
5788 Lincoln Drive 
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that accomplishes task selection is quite 
elegant and because of its inherent repet- 
itive execution, also quite efficient. 

In order to determine the highest prior- 
ity partition ready to run, the dispatcher 
uses two major blocks called the Partition 
Selection String (PSS) located at X'258’ 
and the PPRTYOWN table located at 
X'2C4'. Both of these blocks contain in- 
formation for each partition in priority se- 
quence and thus are rearranged by the VSE 
PRTY command as well as by the system 
partition balancer. The PSS string con- 
tains one bit for each partition in the sys- 
tem. If the bit is zero, the partition is not 
ready to run and likewise if it is set to 
one, the partition is ready to run. The 
PPRTYOWN table contains fullword 
pointers to each PCB in the system in 
priority order. The dispatcher first locates 
a non-zero bit in the PSS and then uses 
the relative location of the bit to index 
into the PPRTYOWN table to locate the 
PCB for that partition. An example of this 
technique is shown in Figure 3. 

After locating the ready partition, the 
highest priority ready task within the par- 
tition must be located. For this the dis- 
patcher uses the Task Selection String 
(TSS) located within the partition 
PCB + X'18'. Within the TSS there is one 
bit for each of up to 31 subtasks and the 
maintask. These bits are in task priority 
sequence within the PCB and correspond 
on a one-for-one basis with the Task ID 
String (TIDSTR) bytes located at 
PCB + X'20’. Like the PSS scan, the dis- 
patcher again uses a Translate and Test 
(TRT) instruction to determine the rela- 
tive task that is ready to run within the 
ready partition and uses this as an index 
to load the Task ID (TID) (see Figure 3). 
From the TID, all other necessary control 
blocks can be calculated using TIBATAB 
and so on and the task can be activated. 

Through a graceful and speedy process 
the dispatcher has determined the task in 
the system that is worthy of its resources. 
It then initializes the major control block 
pointers including the PCB, TIB, TCB 
and PIB in the Fixed Control Area and 
additionally stores the TID at X’5A’ into 
SYSCOM indicating the last task dis- 
patched and the partition’s COMREG at 
X'16’ into low core. Then, the task’s save 
area is addressed, the PSW that was saved 
at the moment of GENENT during the 
interrupt is restored to ERA and the su- 
pervisor exits its code and activates the 
task by restoring the task’s general reg- 
isters and issuing a load PSW instruction 
(see Figure 3). 
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Haven’t we been here before? 


We have now gone full circle from task 
execution to interrupt to task execution 
again. The rather swift selection mecha- 
nism of the VSE dispatcher is necessary 
when you consider the literally millions 
of passes through this code during the life 
of an IPL. Surely you must agree that the 
VSE dispatcher is ‘‘a traffic cop extraor- 
dinaire.”’ 


Now, the control blocks written about 
as old friends have begun to take life in 
the heart of VSE: the supervisor. These 
articles are building to the ultimate dis- 
cussion of VSE problem determination 
and debugging. In the next peek ‘‘under 
the covers,’ some aspects of VSE stor- 
age management and layout will be ex- 
amined. = 
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Example Of Task Selection Routine 


Determine the highest priority partition ready to run 


R1,R1 

R2,R1 

PSS(LPSS), PREXTTAB 
ND 


R1,5 
R5,0(R2,R1) 
R5,PPRTYOWN-4(R5) 


L 
USING PCBADR, RS 


CLEAR REGS . . 
.. FOR TRT 
SCAN FOR READY PARTITION 
GOTO ALL BOUND IF NONE 
CALCULATE DISPLACEMENT 
. TO THE PARTITION’S 
. . PCB POINTER 
LOAD PCB ADDRESS 
SET TO DSECT 


Determine the highest priority ready task within partition 


TSS, PREXTTAB 
R8,TSS 

R1,R8 

R1,3 

R2,2 

R1,R2 

R1, TIDSTR-1(R1) 


FIND READY TASK 
CALCULATE DISPLACEMENT 
. . TO TASK’S 


PCB 
LOAD TASK ID 


* Task is selected, exit supervisor and activate task 


RB, TCBSAVE 
SVEARA,RB 


ERA(8), SVEPSW 
R9,R8,SVERO9 
RID + 1,USERTID 
ERA 
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LOAD PTR TO SAVE AREA 
ADDRESS SAVE AREA 


SETUP PSW 

LOAD TASKS GENERAL REGS 
IDENTIFY TASK 

ACTIVATE THE TASK 


;——— DB2’s Query ——_—_ 


DB2 from page 32 

quired. The IBM sample tables have been 
granted to PUBLIC, so anyone who has 
access to QMF can run queries against 
these tables. 

QMF training requirements have proven 
to be minimal. I have written a users’ 
manual and provide a three-hour intro- 
ductory class for most users. If the user 
is at a remote site or timing for a class 
does not work out, IBM’s Learner’s Guide 
has proven to be useful. The guide is a 
self-paced, hands-on course that has the 
new user write queries from the sample 
tables and create forms for the results. It 
covers the basics but unfortunately falls 
short of explaining how to summarize and 
group data. 

I have had the best response training 
people who have similar information needs 
rather than similar skill levels. This al- 
lows me to customize a class based on the 
data and concentrate on the QMF func- 
tions they will use the most. The func- 
tionality of QMF is extensive, but most 
users will only use a small portion of those 
capabilities to generate their reports. 

One of the most satisfying aspects of 
my job is the feedback I get from new 
users and the users of new tables. Without 
fail, someone calls to tell me how much 
time they have been able to save by using 
QME. They are delighted and usually full 
of ideas for new tables that we should 
create. 

Having supported a number of other 
4GL, user-friendly reporting tools, I can 
honestly say that I have been pleasantly 
surprised by my experience with QME I 
have seen real user acceptance of this 
product and I am continually impressed 
by the minimal support that is required 
for end users. = 
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Free Space Selection, I/O 
Buffer Allocation, Space Allocation And 


rganizational options, flexibility 
and performance are some of the 
reasons why VSAM is a widely- 
used access method. In addition, VSAM 
is relatively compatible between operat- 
ing systems especially at an external level. 
In this series of articles important areas 
of VSAM design and performance are 
explored. Control Interval (CI) Size for 
data and index, Control Area (CA) Size 
and CI/CA Splits and their effect on 
processing were described in detail in the 
January, 1989 issue of MAINFRAME 
JOURNAL. 
Free space selection, I/O buffer allo- 
cation, space allocation and index options 
are addressed in this article. 


Free Space 


VSAM Key Sequence Dataset (KSDS) 
files provide the capability of addition and 
deletion of records as well as alteration 
of the records’ length. In order to provide 
space for this to occur, the FREESPACE 
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Index Options 


By Eugene S. Hudders 


parameter can be specified. Space can be 
reserved at the CI and/or the CA level. 
The major objective is to avoid CI/CA 
splits. Splits, especially CA splits, take 
up resources and time. A CA split in an 
on-line environment can adversely affect 
response time. Thus, the positive effect 
of free space is to be able to add or ex- 
pand records with minimum overhead. 
Also, during split processing the integrity 
of the dataset is in jeopardy until the in- 
dex is updated on the disk. 

There are some negative effects to us- 
ing free space. Free space will increase 
the space requirements and, thus, sequen- 
tial processing time. If a poor free space 
selection is combined with a poor CI and 
CA selection, then the results could be 
disastrous to the performance of the da- 
taset. Therefore, specify free space only 
if needed. If you must specify free space, 
then use it judiciously. 

One characteristic of free space is that 
it is evenly distributed across the dataset. 


Due to this, it is possible to have unusable 
space due to the insertion pattern. This 
leads to wasted space. Depending on the 
distribution of insertions, the user can vary 
the request for free space by specifying 
either CI or CA free space or both. If this 
does not fit a particular dataset, then the 
user should consider writing his own load 
program to create the free space where 
insertions occur. At the point where in- 
sertions are to be made, the load program 
can create dummy records. These dummy 
records are later deleted and the free space 
is created at the point where the insertions 
are to occur. 

The selection of the free space per- 
centage can also be a little confusing. The 
free space percentage is not necessarily 
based on the rate of growth of the dataset. 
CI free space is based on a percentage of 
the CI size, that is, bytes in a logical re- 
cord, not dataset growth. A dataset may 
be growing at a 10 percent rate but if the 
CI size is 4K bytes and each logical re- 
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cord was 1,000 bytes, then a 25 percent 
Cl free space would have to be requested 
to leave space for at least one logical re- 
cord per CI. The CA free space is not 
much better because the idea is to leave 
completely empty CIs. Each CI can usu- 
ally accommodate more than one logical 
record. Thus, using the above example 
(CI FSPC), if there were 150 CIs per CA 
and a 10 percent CA free space was se- 
lected, then 15 empty CIs would be left 
free. As each CI could hold up to four 
logical records, space for a total of 60 
records has been allocated. This may be 
higher than the growth rate. When com- 
bined, CI and CA free space may actually 
reserve a much higher amount of space 
than the growth rate, especially consid- 
ering growth rates are usually given in 
yearly percentages. If the dataset is re- 
organized monthly, then the actual space 
requirements for growth would only be 
one-twelfth of the yearly percentage based 
on an even distribution. 

Unfortunately, a standard formula is not 
available to determine the percentage of 
free space to be used. Factors that will 
affect the free space percentage include 
the CI size, the logical record size, the 
CA size, the distribution of insertions, the 
growth rate and the frequency of reorgan- 
ization. Trial and error is not necessarily 
the best method but it works. Use fre- 
quent LISTCATs to monitor results until 
a good balance is received between splits 
and free space reserved. The general 
guidelines are: 


@ If evenly distributed insertions and/ 
or record expansions, use CI and 
CA free space (especially if on-line 
additions) 

@ If uneven distribution, use CA free 
space 

@ If additions are at the end of the 
dataset, leave no free space but 
allocate a larger primary 

@ If no insertions and/or record 
expansions, do not use free space. 


The LISTCAT will provide information 
(splits) which will give you an idea as to 
the effectiveness of the free space se- 
lected. LISTCATs should be produced 
before and after dataset updates to meas- 
ure results. 


I/O Buffer Allocation 


An important performance feature of 
VSAM datasets is the buffer space allo- 
cation that can be specified. An important 
fact is that the defaults assumed by VSAM 
in the cluster definition are not good for 
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performance in most situations. For se- 
quential processing, additional data buff- 
ers can be specified. For direct process- 
ing, additional index buffers can be 
specified. When accessing the dataset se- 
quentially, VSAM starts at the highest 
level index following the chain down un- 
til the first sequence set index record is 
found. 

VSAM will process all the CIs in the 
CA associated with the sequence set re- 


cord. VSAM will then follow a forward 
pointer (Horizontal Pointer) in the se- 
quence set record to locate the next se- 
quence set (CA) to process. Sequence set 
records are not read ahead; therefore, ad- 
ditional index buffers are usually of no 
value. Data CIs are read ahead if addi- 
tional data buffers are available. Having 
additional buffers usually improves per- 
formance. Too many buffers can increase 
paging and device/channel utilization 


Is Your DASD Space Being Wasted???? 


THEN YOU NEED 
DP VSAM/SR 


THE ONLY PRODUCT THAT CAN IMMEDIATELY RECLAIM 
UNUSED DASD SPACE ALLOCATED TO VSAM FILES. NO 
BACKUPS, DELETES, REDEFINES AND RESTORES OF THE 
VSAM FILES ARE REQUIRED. (MVS ONLY) 


FOR FURTHER INFORMATION CALL OR WRITE: 


DATA PROCESSING TECHNIQUES, INC. 
24 LAKEVIEW DRIVE 

WEST ORANGE, N.J. 07052 

PHONE: 204-325-3251 
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CAN YOU AFFORD NOT 
TO TUNE YOUR VSAM FILES? 


(VSAM problems don't just go away) 


Unlike the highly visible ‘explosive’ problem which causes havoc and demands priority, 
VSAM problems tend to be ‘corrosive’ and often go unnoticed. The forgiving nature of 
VSAM will usually avoid a crisis, but can lead to expensive DASD and CPU inefficiencies. 


ULTIMATELY, A SOLUTION IS NECESSARY! 


Solution 1 — Acquire additional DASD, CPU power, technical people or add an extra shift 
... This option is very expensive ... and only defers the problem. 


Solution 2 — Acquire CBLVCAT ... This option involves a fraction of the cost, a 1d can 


solve the problem in a fraction of the time. 


Ch VCAT VSAM Monitoring, Tuning/Optimizing and 
Modelling for any DOS, CMS, OS, XA system 


Call or write for a free trial and let us help you gain control of your VSAM files. 
Tel: 416/746-4447 Compute (Bridgend) Ltd, 38 Guided Ct, Rexdale, Ontario, Canada 
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which may affect the performance of the 
entire system. Too few buffers, such as 
the default value, can also affect the per- 
formance of the program especially if the 
CI size is small. The default data buffer 
space is twice the data CI size. After a 
certain number of buffers (for example, 
three or four), VSAM will attempt to read 
more than one buffer with only one phys- 
ical read operation. This is a chained CCW 
I/O operation. In addition, if sufficient 
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buffers are provided, VSAM will split the 
buffers so as to provide overlap process- 
ing and chained reading. Overlap pro- 
cessing is like having an alternate area 
available to process while filling up the 
alternate area. 

Direct processing, on the other hand, 
makes more use of index buffers to search 
for the desired record. VSAM will use the 
extra index buffers to maintain the indices 
in storage for future reference and use. 


Screen Painting and Conversation 
Prototyping for CICS and IMS/DC 


Quick Screen 3270 is a new and easy to use PC based development tool. It will 
help you create screens and demo systems in minutes instead of hours! 


Quick Screen 3270 features include: 
fast. WYSIWYG (what you see is what you get) map entry 
advanced, powerful word processing and SPF type editing 
integrated map editing and conversation prototyping 
generate and import CICS/BMS and IMS/DC/MEFS code 


5 windows to work in 


context sensitive help and pop-up screens 
no programming background required for its use 


Compare Quick Screen 3270 to SDF2 or to whatever you use today. Call or write 


FREE 60 Day Trial! 


Integrated Systems Technology, Inc. 


5 Chapel Hill Road, Short Hills, NJ 07078 
(201) 376-3722 


for a free guide or a 
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Compression for V 


Automatic Dat 


T 


ws 
SE 


Saves VSAM space by 50% or more 

Supports KSDS, ESDS and Managed-SAM 

Easy to use—no JCL changes, no program changes 
Reduces DASD |/O activity; Improves system performance 
Improves online response times; Speeds tape backups 
Analysis Utility forecasts actual space savings 


Call now for your FREE copy of the Compression Analysis 
program that will show how much disk space your installation 


can save by using VSAM-LITE. 


CALL... 
Toll Free: (800) 243-9542 
in Conn: (203) 792-5100 
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Universal 
ftware: 


Brookfield Office Park 
Brookfield, CT 06804 


CIRCLE #112 on Reader Service Card A 


This will improve future data record ac- 
cess if the indices are in storage. Extra 
data buffers are usually of no value unless 
a spanned record is being read. The actual 
number of index records in storage de- 
pends on many factors such as the buffer 
pool management techniques (LSR versus 
NSR). 

The default index buffer space is one 
buffer. Thus, for a three index level da- 
taset, three reads to the index portion are 
required. Each index read destroys the 
contents of the previous level. This causes 
the indices to be re-read for every direct 
access. Ideally one would want to have 
extra index buffers in order to keep the 
higher level indices in storage so that they 
will not have to be re-read for every direct 
access. 

There are several ways to specify extra 
buffers to a VSAM cluster. We will dis- 
cuss some of the most common methods. 
The first method is to use the buffer space 
parameter (BUFFERSPACE) during the 
cluster definition. This is not recom- 
mended except for the base cluster when 
accessing an alternate index via the path 
in an on-line environment. The main dis- 
advantages of this method are that any 
change in the CI size (data and/or index) 
will require a change in the BUFSP spec- 
ification. The decision as to how many 
buffers of each type (data or index) is left 
to VSAM based on the mode of process- 
ing specified at dataset open time. This 
can be misleading if the dataset is opened 
for dynamic processing. 

Another method is to run an IDCAMS 
ALTER to change the BUFFERSPACE 
allocation prior to execution and possibly 
after execution to restore the original val- 
ues. This takes extra processing time and 
is not recommended. 

A more dynamic alternative is to spec- 
ify the required amount (BUFSP) in the 
execution JCL (// DD or // DLBL). This 
is the preferred method for batch pro- 
cessing. For DOS users, the amount of 
buffer space desired is defined through the 
BUFSP parameter in the // DLBL card. 
For MVS users, the BUFSP subparameter 
of the Access Method Parameter (AMP) 
can be used. The user has to determine 
the correct amount based on the CI sizes. 
Buffer space allocations in the JCL are 
also sensitive to change in CI sizes and 
mode of processing. This is similar to de- 
fining the buffer space at cluster definition 
and thus has the same disadvantages. 

In order to better distribute the buffer 
allocations, MVS provides the subpara- 
meters BUFND and BUFNI also of the 
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AMP parameter in the // DD card. These 
subparameters provide the capability of 
requesting a specific number of buffers 
for the data (BUFND) and index (BUFNI). 
This selection is independent of the CISZ. 
Therefore, one can change the CISZ and 
VSAM will compute the necessary buffer 
space. These parameters also provide the 
user with a means of controlling the num- 
ber of index and data buffers desired 
whenever the dataset is processed dynam- 
ically based on the user’s knowledge of 
the dataset processing requirements. 

A major point of discussion when deal- 
ing with buffering and sequential pro- 
cessing is the CISZ to be used. Are large 
CI sizes better than multiple data buffers? 
The answer lies in the amount of re- 
sources (for example, central storage) 
available. A CISZ in the 4-8K range cou- 
pled with 6-8 data buffers will yield good 
performance while maintaining adequate 
use of resources. 

Considerations for on-line datasets will 
be discussed in the CICS/VS section. The 
request for buffers should be done through 
the File Control Table (FCT) utilizing the 
BUFNI, BUFND and STRNO parame- 
ters. The actual requirements will depend 
on the individual dataset being defined. 


Space Allocation 


When requesting space for a dataset, 
the important aspect is to ensure sufficient 
space in the primary so that no secondary 
allocations take place. The total space used 
after loading the dataset should be around 
90-95 percent. This can be verified in a 
LISTCAT using the High Used RBA 
(HURBA) and the High Allocated RBA 
(HARBA). Additional space may be al- 
located if the dataset receives extensions. 
Secondary allocations should be taken as 
an indication that more space in the pri- 
mary is required. Secondary allocations 
take up virtual storage and the dataset may 
be spread across a volume that may affect 
sequential processing. Also, when re- 
questing space, be sure to request suffi- 
cient space for the secondary. Small sec- 
ondary allocations (for example, one 
cylinder) can cause a high overhead when 
repeated secondary allocations are re- 
quired. 

Key ranges are another feature of space 
allocation where the user can distribute 
the data across several volumes. The idea 
is to provide a certain amount of overlap 
capability. There are certain things that 
must be observed. The split by key ranges 
has to be well planned to ensure a balance 
of total data and number of accesses. As 
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each new volume is allocated, a new pri- 
mary allocation is made. This can lead to 
unused space and/or over-used space if 
the data is not properly partitioned. The 
key ranges selected should include all key 
possibilities. Any key not included in the 
ranges will not form part of the dataset. 
If any overlapping is to exist, then the 
index records should be brought into stor- 
age. Otherwise, the access to the dataset 
will single thread through the index por- 
tion on disk. 


80 percent. 


50 percent. 


fifth the time of BLDINDEX. 


VSAM data sets in minutes. 


Pe 


/ 


Index Options 


# VSAM I/O Plus™ slashes VSAM batch processing time up to 


= VSAM Assist ™ backs-up and restores VSAM files 70 percent 
faster than EXPORT & REPRO. 


= VSAM Data Compressor™ cuts VSAM DASD space by 


= VSAM Space Manager™ pools VSAM DASD and eliminates 
ABENDS due to lack of space. 


# VSAM Quick-Index™ loads VSAM alternate indexes in one- 


= VSAM Mechanic™ recovers or repairs broken ICF catalogs and 
For more information call 


800-638-9254 


MVS only. 


O 


ll sor 
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Several index options are available to 
the user. IMBED and REPLICATE make 
use of the disk areas to improve direct 
access. Another option is to bring in as 
many indices into virtual storage as pos- 
sible. IMBED will take the Sequence Set 
Index (SSI) and write it with the data in 
its respective CA. As the whole first track 
of the CA is dedicated to the index, the 

See VSAM Optimization page 92 
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One product and one hour 
could double 
VSAM performance 


OOD 


HYPER-BUF 
VSAM buffer allocation expert 


e Shatters VSAM performance barriers 
— Customers consistently report 25% to 80% 
reduction in EXCPs 
© Optimizes CICS buffers 
¢ Installs in less than one hour 


Other VSAM products from Goal Systems, the Original 
VSAM Experts 


/* FAVER — A VSAM file management tool with comprehensive reorganization and 
backup/restore capabilities. 
VSAMAID — Tunes VSAM datasets automatically while eliminating inefficiencies. 
A cluster modelling, performance, and capacity planning tool. 
MASTERCAT — An online and batch VSAM catalog navigation tool. 
COMPRESSOR/MVS — Provides compression of VSAM datasets. Can triple disk 
capacity. Available for MVS. 


To Find Quality Call 800-848-4640. 


All products, except COMPRESSOR/MVS, are available for VSE and MVS.*/ 


Op” 


Goal Systems International * 7965 N. High Street * Columbus, Ohio 43235 * 800-848-4640 


Goal Systems International S.A.R.L. * 88 avenue de Wagram * 75017 Paris, France * Phone (1)42 67 55 55 * Telex: 641.094 
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he inherent nature of an on-line system such as 

CICS implicitly provides a measure of the effi- 

ciency of a computer center and its service to the 

user community. This article addresses the prob- 
lems encountered in performance analysis by presenting 
a technique that allows the assimilation of all data made 
available to the analyst. The theories presented here are 
the basic mathematical premise for a total tuning phi- 
losophy. The technique will allow its adherents not only 
to predict how their system will perform in the future, 
but also to help in pinpointing system problems before 
they severely degrade system performance. Only the 
basic foundation for the approach is presented here as 
a complete explanation of all the implications would 
require an article of substantial volume. The object in 
mind is the successful implementation of performance 
monitoring, statistical analysis and tuning to ensure the 
efficient use of resources resulting in faster response 
times, higher levels of productivity and enhanced user 
confidence in data processing. 


Monitoring Tools — Collecting the Data 


— 


es SS pice Srp 
.") LAK be Val MARE (As There are many software vendors who provide sys- 
iT, TKN tems programmers with the tools they need to accom- 

iv -sealgingalgle <8" plish the goal of getting the most out of a system. How- 

ever the questions arise, ‘“What do I look for in a monitor 
and once I have selected one, how can I use the infor- 
mation that it provides?’’ 

An effective CICS monitoring tool must display data 
associated with system resources as they are being used. 
This feature makes it possible to ascertain how system 
resources are being utilized and under what circumstan- 
ces a particular resource or transaction is degrading sys- 
tem performance. On-line, real-time intervention, to al- 
leviate system problem events, is helpful to relieve 
system hangs and to prevent subsequent shutdowns. The 
dynamic character of CICS makes it difficult to evaluate 
the effect of any tuning effort on overall system per- 
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formance, thereby making evaluation of 
archived data essential. 

A good CICS measurement tool must 
also be able to collect and archive system 
data so that reports can be generated to 
detail and summarize this data into daily, 
weekly and monthly reports. With this fa- 
cility at hand, it is a simple matter to dis- 
cover system trends and to effectively in- 
itiate system capacity planning. Although 
there are many facets of CICS that are 
reported on and archived, there are six 
system measurements that avail them- 
selves as critical to predicting overall CICS 
performance. These are: 

. Transaction activity rate 
. File activity rate 

. Paging rate 

. File response time 

. CICS response time 

. CPU utilization. 

Each one of these aspects of the system 
are related and affect one or more of the 
others. The problem now arises, ‘‘How 
do you take the information provided by 
a monitor and correlate it into a form that 
is useful?”’ 


An kWNe 


Statistical Theory & Performance Data 


Mathematical Tools — 
Statistical Theory 


Linear Regression 

and Correlation 

Linear regression is a statistical method 
used to determine a linear equation that 
describes a straight line relating two var- 
iables. The linear equation is usually in 
the form: 


Y=MX+B 
Where: 
Y =dependent variable 
M =the slope of the line: RISE 
RUN 


X =independent variable 
B =the Y intercept 


Linear correlation is a statistical tool 
used to analyze the relationship between 
two variables and to determine the extent 
of that relationship. The linear correlation 
coefficient is found by using the equation 
in Figure 1. 

A resulting value near one indicates a 
strong relationship between the two var- 
iables. A value of near zero indicates that 


“R-TEST” Table 


# of 
Samples 80% 90% 
29 245 311 
30 241 306 
31 .237 301 


95% 99% 
367 471 
361 463 
355 .456 


99.9% 
O19 
570 
562 


Note: If the correlation coefficient is negative, use the absolute value but keep in mind 


that the relationship is inverse. 


xX 
(Hypothetical or 
previously calculated X) 


gee eS EE. ee a ie 
.\2 


Where: 
Y =predicted value of dependent value 


X =hypothetical or previously calculated value 


of independent variable 
Y; =singular occurrences of Y 
Data 
Xj =singular occurrences of X 


N =number of paired occurrences of X and Y 
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ee 


2x) 


ee NExy — (2x)(y) 


\/ N(2x2) - (2x)? \/ Ny) — (ay)? 


Where: 
N =the number of paired samples 
= =the operation of summation 
X =the independent variable 
Y =the dependent variable 


the variables are only minimally related 
and a value near minus one indicates a 
strong inverse relationship. Table | gives 
you the corresponding significance be- 
tween two variables. 

Using, for an example, the value of 
R=.45 for 30 observations, it is found 
that the value is between the 95 percent 
and 99 percent columns giving us a greater 
than 95 percent significance between the 
two variables. 

Assuming acceptable correlation be- 
tween two variables, further analysis can 
be conducted and the exact nature of the 
relationship can be expressed. Using the 
following form of the linear equation, we 
can predict a Y value given an X value 
as in Figure 2. 

Once your prediction is found using the 
linear equation above, you must qualify 
the prediction with a confidence interval. 
This can be expressed as the degree of 
certainty that your predicted mean will fall 
into a given range. It is found by using 
the equation in Figure 3. 


Where: 
X =your predicted mean value 
Sx =standard deviation expressed as: 


2 = x) 
N 


C= 


N =number of paired observations 
Z =value from table of Z-scores 


Z-SCORES TABLE 

Degree of 

Certainty Z-Score Value 
60 84 
65 94 
70 1.04 
75 1.15 
80 1,28 
85 1.44 
90 1.65 
95 1.96 


2.58 
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Predicting Next Month’s 
Response — What to Do 
with the Data 


Now that you have been severely beaten 
around the head with statistical theory and 
equations, what, you may ask, can I do 
with all of this? The answer is to plug and 
chug. That is, plug in your data and chug 
through the equations. 

Table 2 is a typical month’s worth of 
performance data provided by a typical 
monitor. We will use this data as an ex- 
ample. 
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FlGURE 4 


- (81)C-2925295) — (.8734)(10.1693) 


\/ (31)(.0248424) — (.8734)2 \/ (31)(8.8489436) — (10.1693) 


9.0684145 — 8.8818666 


VV .7701144 — .7628276 \/ 119.31725 — 103.41466 


: 1865479 
(.0853628)(3.9878052) 


5480091 


Using Table | you will find the linear 
correlation coefficient of .548 for 31 sam- 
ples gives a greater than 99 percent sig- 
nificance. 

Now that you have established that 
the relationship between file I/O and 
CICS response is greater than 99 per- 
cent significant, plug the values into 


ia ae 
PERFORMANCE DATA 
C.1.C.S. FILE 1/0 
DATE RESPONSE TIME RESPONSE TIME 

03/01/88 0.4301 == ji 

03/02/88 0.7862 = = : 

03/03/88 0.3682 = = y 

03/04/88 0.3311 == ! 

03/05/88 0.2062 = = i 

03/06/88 0.1834 = = ; 

03/07/88 0.3390 = = i 

03/08/88 0.3280 = = A 

03/09/88 0.3204 = f 

03/10/88 0.3480 = i 

03/11/88 0.3131 = x 

03/12/88 0.1831 = i 

03/13/88 0.1661 = A 

03/14/88 0.3366 = H 

03/15/88 0.3578 = H 

03/16/88 0.3481 = , 

03/17/88 0.3440 = 

03/18/88 0.3202 = ; 

03/19/88 0.1837 == 0.0299 

03/20/88 0.1931 = = 0.0266 

03/21/88 0.2981 == 0.0236 

03/22/88 0.3305 = = 0.0243 

03/23/88 0.6927 = = 0.0340 = = === 

03/24/88 0.3394 == 0.0299 = = == 

03/25/88 0.3492 == 0.0303 = === 

03/26/88 0.1783 = = 0.0295 = === 

03/27/88 0.2431 === 0.0258 = === 

03/28/88 0.3353 = === 0.0249 = === 

03/29/88 0.3128 === 0.0268 = = == 

03/30/88 0.3743 ==== 0.0297 = === 

03/31/88 0.3292 === 0.0283 = === 
Boxes: 0.3583 = === 0.0282 = === 


For reasons of brevity I will not cover 
the process of multiple regression that is 
required to establish the relation between 
the six elements for which we have col- 
lected data. To illustrate the application 
of the theory, I will use CICS response 
time as it relates to file response. This will 
require the use of the equation for finding 
the linear correlation coefficient discussed 
earlier, but first you must break down the 
elements as required by the equation: 


N=the number of paried observations = 31 

=X =the summation of file I/O times = .8734 secs. 

XY =the summation of CICS response times = 10.1693 secs. 
XY =the summation of the products of XY = .2925295 secs. 
=X? =the summation of (1/0 times)? = .0248424 secs. 

XY? =the summation of (CICS response)? = 3.8489436 secs. 


We now plug our values into the equa- 
tion in Figure 4. 
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(.8734)(10.1693) 
31 


8734)? 
—— — 0248424 


— ,2925295 


the linear equation which will then serve 
as a model for the relationship (see 
Figure 5). 

Reduction of this expression results in 
a more familiar form, giving us an equa- 
tion that best describes the line correlating 
file I/O times and CICS response for the 
month of given data (see Figure 6). 


(.8734)(10.1693) em 


10.1693 _ 


31 


8734)? 
ay ene 0248424 


2865118 — .2925295 x 
0246073 — .0248424 


+ 4 3280419 — 


y — | =060177 
— 0002351 


Y = 25.596342 X + 


Y 25.596342 X + 


X +4 3280419 — 


31 


2865118 — .2925295 
0246073 — .0248424 


(.0281742) 


— 0060177 


ee (.0281742) 


— .0002351 


3280419 — (25.596342)(.0281742) 


— 3931146 


ys 25.596342 X — .3931146 
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We can now use this equation to predict 
CICS response given any file response by 
replacing the X variable with a hypothet- 
ical or previously predicted value for file 
response. 

Say that we have predicted by using 
similar techniques as explained above a 
mean file I/O time of .030 for next month. 
If we just plug that value into the X var- 
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iable, we can then determine what our 
CICS response for next month should be: 


Y = 25.596342(.030) — .3931146 
Y = .3747757 
Validation of this prediction is accom- 
plished by providing a confidence interval 


within which the prediction will fall (see 
Figure 7). 


Problems: 1. cics, ims, vTAM and TSO users need 
access to an online editor and JES. 


2. General user access to ISPF is limited 
because of required use of TSO and its 
associated system overhead. 


Solution: 


BIM-EDIT/MVS—Online Editor System 


Online Editing and Access to JES from CICS, IMS, VTAM or TSO 


BIM-EDIT/MVS has been designed to eliminate many of the problems associated with using TSO/ISPF. 
Because TSO is required to use ISPF, general user access to it is sometimes limited because of system 
overhead restraints or the fact that the user simply does not have access to TSO. BIM-EDIT/MVS runs 
in its own region independent of any MVS subsystem and can be accessed directly from VTAM, CICS, 
IMS or TSO concurrently. Unlike TSO/ISPF all BIM-EDIT/MVS users run in the single BIM-EDIT/MVS 
region. Due to single region implementation, BIM-EDIT/MVS should support as many as four times the 
number of users as TSO/ISPF, using a similar amount of system resources. 


Also, BIM-EDIT/MVS is a very powerful, flexible and easy to use editor which contains many features 
which should greatly enhance the productivity of your programming staff as well as other end users needing 
access to an on-line editor. 


Here are just a few of the many reasons you should look at BIM-EDIT/MVS: 


e Commands can be entered in any environment, 
eliminating the need to exit one function and 
enter another. For example, while editing a 
member, a command can be entered to display 
the JES queues. 


Commands may be chained together in any 
combination, executed as a group and can cross 
“modes’’. 


Commands, command groups and BIM-EDIT 
procedures can be assigned to PF or PA keys for 
execution by user. 


Up to 9 active concurrent BIM-EDIT/MVS 
sessions per user, rotate between them via a PF 
or PA key. 


Access to JES spooling queues. Jobs and job 
output can be listed, altered and purged. JES 
queue directories can be listed. 


Access to partitioned data sets (PDS’s). Members 
can be created, listed, edited, and purged. 
Directories can be listed. 


e Stack area provided to facilitate moving text 
between members. 


e BIM-EDIT/MVS can be accessed on-line from 
VTAM, CICS, IMS, TSO, and also from its batch 
utility and from the user application interface, 
concurrently. 


Single-region implementation of BIM-EDIT/MVS, 
unlike ISPF which requires a region for each 
user, should allow BIM-EDIT/MVS to support up 
to four times the number of users as ISPF utilizing 
a similar amount of system resources. 


* Tight source control with member auditing and 
stamping, purge control mechanism and 
checkin/checkout function. 


* A powerful easy to use procedure processor. 
Flexible and straightforward security. 


Outbound screen data compression for optimum 
response time, including suppression of 
characters previously at the same screen 
position. 


e Automatic disk space compression. 
e Full function Electronic Mail System. 
* Maximum compatibility with BIM-EDIT/DOS. 


BIM-EDIT/MVS is priced at $11,200 for a permanent license, $5600 on an annual lease or $560 on a 


monthly rental. 


B | Moyle Associates, Inc. has been dedicated to providing cost effective software solutions, which improve 
system performance and user productivity, for 10 years. For more information on BIM-EDIT/MVS, or any 
of our other quality software products and services call Jim Kingsbury at 612-933-2885 today. 


[325[M 


B | MOYLE ASSOCIATES, INC. 
5788 Lincoln Drive 
Minneapolis, MN 55436 


612-933-2885 
Telex 297 893 (BIM UR) 


Member Independent Computer Consultants Assn 
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Where: 
Y=predicted CICS response mean 
= 8747757 secs. 
Sy =standard deviation in the form: 


oO — 
Where: 
Y; =each observation of CICS 
response 
Y =mean of CICS response 
= 3280419 secs. 
N =number of observations = 31 
Go = .9129867 
31 
a= .1286389 
*Z= Z-Score derived from Z-Score 
table: we will use a 99% degree 
of certainty, as the degree of 


significance in the predicted 
value is > 99% = 2.58 


=a 
. = 3747757 — (2.58) 


a 


p = 3747757 * 9°90089 @ gox 

This expression is telling you that with 
a 99 percent degree of certainty we can 
expect, given a file response mean of .030, 
that our CICS response mean will fall into 
the range between .31517 and .43438. 
(Note: traditionally the degree of certainty 
is a subjective call based on factors con- 
cerning confidence in the measurement of 
the data collected.) 

What inferences can be made with this 
information? Suppose that the actual mean 
value of the predicted month for file I/O 


See Statistical Theory page 94 
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your systems support becomes terminal...contact ISS. 


Some of our services include: 


@ System generation DOS/VSE, MVS 
VM, CICS, IMS, VTAM 


® Conversion CPU upgrades: 43xx, 
303x, 308x, 309x 
Telecommunications: BTAM, VTAM 
OEM Software Packages: Disk and 
Tape Management 


® Performance evaluation & tuning 


® Resource capacity planning 


@ On-demand technical support 
@ 24-hour emergency support 

@ Site survey (software & hardware) 
® On going systems support 

®@ Remote systems support 


USA (818) 966-0227 Jol 
LONDON 01-642-4242 
BRUSSELS 01-736-9713 


A Galliard Company j S&S 
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Managing 
DASD Performance 
Can Be a Pleasure Trip... 
Not a Survival Course 


DASDMON will revolutionize the way you manage MVS 
DASD performance. 


Traditional DASD tuning techniques are being outpaced by 
faster CPUs and increasing user demands for more online 
data. Although cache controllers, data spaces and hiper- 
spaces will relieve some of the strain, they also create 
new complexities. Tuning DASD can feel like struggling 
through a survival course. 


DASDMON takes you away from it all 


DASDMON offers you system managed performance 
today. By cutting through the complexities of conventional 
tuning, managing DASD performance is more automatic 
and streamlined than ever before. Once you've set 
response time objectives, just sit back and... 


* DASDMON will identify problems by continually 
measuring individual I/O response times and comparing 
them to your objectives. 


¢ DASDMON will determine the cause of problems by 
gathering and analyzing data. No longer will you spend 
hours scanning reports. 


¢ DASDMON will present solutions to your problems in 
precise English, and simulate their effects to ensure that 
a new problem is not introduced. 


* DASDMON will select the best possible set of solutions 
so you can implement recommendations with confidence. 


And, if you have any questions or concerns along the way, 
our experienced technical support staff will be glad to 
guide you—24 hours a day. 


To maximize your system's overall performance, use 
DASDMON with our DASD Performance Optimizers. These 
products eliminate DASD I/Os, resulting in automatic 
response time reduction. 


For more details, call (800) 323-2600 or (412) 323-2600 in 
Pennsylvania. Ask for Extension 333. 


Performance and Optimization products from Duquesne 
Systems. Enjoy the results. 


DUQUESNE 
SYSIeEllio 


Two Allegheny Center 
Pittsburgh, PA 15212 
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—— ISPF Techniques — 


ISPF Techniques from page 39 

little common sense, the additional re- 
sources consumed by ISPF are more than 
offset by improvements in programmer 
productivity. 

When running ISPF in TSO, two fac- 
tors can really make the difference be- 
tween a responsive, low overhead system 
and a slow resource hog. Both signifi- 
cantly reduce DASD I/O. Commonly-used 
portions of TSO and ISPF should be in 
the Link Pack Area (LPA). All datasets 
should be optimally blocked. For 3380 
DASD, this normally means the largest 
block size possible that is less than or equal 
to 23,476 characters (32,760 is the largest 
ISPF can handle). Although not an insur- 
mountable problem, attention should be 
paid to programs that will read the dataset 
to be sure they can accept blocks that 
large. This usually means modifying 
buffer size parameters for compilers and 
utilities and removing any hard-coded 
block sizes for in-house COBOL pro- 
grams. MVS’ rule about concatenating 
datasets with JCL DD or TSO ALLOC 
statements, in which no dataset can have 
a larger block size than the first dataset 
of the list, is another area to watch. Cod- 
ing a DCB=BLKSIZE = 32760 on the 
first DD of a concatenated set is the safest 
solution to that potential problem. 


Your Turn 


You have had a chance to read some of 
the ISPF techniques I have collected from 
my own experience and from those peo- 
ple I have worked with over the last few 
years. Now, it is your turn. If you know 
or find some ISPF techniques that could 
help make other readers more productive, 
please take a moment to tell us about them 
here at MAINFRAME JOURNAL either 
by the Feedback Card or by letter. If there 
is sufficient material, we will keep you 
updated on newly-discovered techniques 
in future issues. = 
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ABR * CPK * FDR * ABR ¢ CPK * FDR * ABR 


Senior System 
Software Developers 


6+ years exp. in dealing with 


MVS - IOS - Disk - Tape - 


Catalog and File Management 


Opportunities available in product development and 


support for the #1 products in DASD Management. 
FDR, COMPAKTOR and ABR have a reputation 


for being the most reliable and efficient programs for 


backup and disk management. 


Comprehensive health, medical and fringe benefits. 
Salary commensurate with ability. Paid relocation. 


If you want to join a technically motivated team, please 
send resume or call describing your accomplishments to: 


Tom Meehan 201-890-7300 


FDR — The Fastest DASD Management System... 


1 ge INNOVATION 
@n” DATA PROCESSING 


Innovation Plaza, 275 Paterson Ave., Little Falls, NJ 07424 
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Q: What do 71. ofthe Fortune 100 


companies have in common ? 
A: A cost effective dataentry 
method utilizing ODE ITs 
integrated on-line/PC system. 


ODE I1 is state-of-the-art data entry software that replaces any key-to- 
disk, key:to-tape, or card system at a fraction of the cost. It was 
designed for data entry on an IBM Mainframe and IBM PC or plug 


compatible. A few of the benefits ODE II offers are: 
© Flexibility to design applications on-line or the PC. 


® Compatibility with any, micro to mainframe link or emulation 
program. 
© Usability through features such as built-in EDITS, subsecond 


response time and menu-driven approach. 


ODE II is reasonably priced, provides flexible lease plans, low 
maintenance and offers a 90-day unconditional warranty after 
purchase. For additional information or to arrange a no obligation 


30-day trial, call 1-800-633-4748. 


(IDF: 


ON-LINE DATA ENTRY 


1112-7th Avenue rc 
Monroe, WI 53566-9982 
1-800-633-4748 
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VSAM Optimization from page 81 

SSI record is repeated the number of times 
that it will fit into the track. This reduces 
rotational delay as any record on the track 
would have the same information. The 
cost is one track of every CA in the da- 
taset. If the CA size was specified incor- 
rectly, then the cost can be high. If the 
CA size is set to the maximum (one cyl- 
inder), then the cost will vary from around 
three percent (3350) to eight and one-third 
percent (3375). On a 3380, IMBED rep- 
resents almost seven percent of a cylinder. 


Mu Multiple VTAM Sessions 
11 for each Terminal 


DOS - $1,495 
MVS - $2,995 


OTHER SOFTWARE 


e Does not affect user’s transaction 
@ Saves screen buffer, Tran-id, and 
Commarea and displays the message 
e Message can be sent to one terminal 
or Operator (OPID), set of terminals 
or Operators, all terminals or console 
e Messages can be sent using a supplied 
CICS transaction or by LINKing to 
the message program 
$695 for purchase 


eS a 


IDCAMS LISTCAT 


VSAM Optimization & Design 


If DASD space is critical, IMBED may 
make it worse especially if a poor CA size 
is defined. As discussed earlier, IMBED 
is not recommended for datasets with less 
than one cylinder in size when the CA is 
made to its maximum size. This is be- 
cause only one index record is generated 
and should be in storage. Also, if the da- 
taset occurs in many splits, the updating 
of the index will take additional time be- 
cause a full track has to be updated rather 
than an individual record. 


VTAM/SWITCH allows users 
to switch from VWTAM application 
to VTAM application (CICS, TSO, 
ICCF, IMS, TESTCICS, etc epby 

§ pressing a PF/ PA 
Multiple sessions of 
the same 
VTAM 
application 
are also 
allowed. 
Applications 
can be 
connected 
automatically. 
Security can be 
specified at the user, 
application, physical 
and logical terminal 
level. Predefined 
LOGON procedures 
can be set up for 
each user 
or for groups of users. 


Recapture wasted disk 
space, save time and 

r by usi 
LI PAT PLUS 
Lists VSAM entries 
(including ICF VSAM) 
in one-line-per dataset 
format. Flags VSAM 
inefficiencies. Datasets 
needing attention 
can be flagged. Lists 
non-VS,. entries 
in ICF catalogs, too. 


LISTCAT PLUS 


Over 30 other products to choose from for CICS and BATCH. 
Each available for FREE 30 DAY TRIAL, purchase, or annual lease. 


MacKinney Systems (417) 882-8012 


2740 South Glenstone, Suite 103 Springfield, Missouri 65804 
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REPLICATE instructs VSAM to assign 
one full track to each index record in the 
index portion of the dataset. Since each 
index record is assigned its own track, the 
index record is repeated the number of 
times it fits into one track reducing rota- 
tional delay in the access. Once again, 
extra disk space is used. 

By far the best option, especially for 
on-line processing, is to load the indices 
into virtual storage. This reduces physical 
accesses to the disk and will improve re- 
sponse time. The cost in this case is vir- 
tual and processor storage. If these are 
available, then this is the preferred op- 
tion. The minimum area allocated should 
be at least one index buffer per index level 
in the dataset. Ideally, the entire Index Set 
should be resident in storage for optimum 
performance. Index records are brought 
into storage as required (no read ahead). 
The number of buffers recommended will 
be reviewed in the CICS/VS area in 
greater detail since direct processing usu- 
ally is more frequent in an on-line envi- 
ronment. 

The use of the different index options 
will depend on the environment. If DASD 
space is available, then IMBED and REP- 
LICATE can be used. If virtual storage is 
available, then allocate additional index 
buffers. If REPLICATE is to be specified, 
then we suggest that IMBED be specified. 
With REPLICATE, the price of IMBED 
is paid but all of the advantages are not 
achieved. IMBED provides the potential 
reduction of arm movement between the 
SSI and the data depending on whether 
the arm is still in position or has been 
stolen by another request. This will de- 
pend on the disk activity. 

In the next issue, the following areas 
will be examined: CICS/VS and on-line 
VSAM processing and miscellaneous 
considerations. = 
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Capitalize On 
Greater Performance 


You don’t have to be a member of Congress to 
meet distinguished colleagues in Washington, 
D.C. At the third annual Candle Performance 
Conference this spring, you'll be part of a 
history-making agenda. It’s the premier 
forum for the performance and tuning 
experts who run today’s high-per- 
formance online systems. The 
conference offers more than 
60 sessions under one roof, 
all for the price of a single 
conventional class. 

Watch Performance 
Blossom 

Only the 1989 Candle 
Performance Conference 
offers this much imme- 
diately applicable 
information on system 
performance...insights 
that can quickly boost 
your data center’s 
productivity and service 
levels. In addition to 
the environment- ws 
specific sessions, pee. 'Candle: 
yl ao bent | | eee 


from the scores of “ Los Angeles, CA 90025 


in-depth seminars on networking, automated 
operations, and performance management 
trends. Your session instructors are all industry 
veterans with years of hands-on experience. 
And because the focus throughout is on 
learning, not note taking, detailed 
conference transcripts are distributed 
free to all participants. 

Don’t Filibuster — Enroll 
.. Now for Special Discounts! 
mm. The conference fee of $1,500 
is a real bargain because it 
includes admission, docu- 
mentation, and all hosted 
meals. And you'll save 
$200 if you register before 
March 30, so don’t let 
your savings get hung up 

in committee. Enrollment 
is limited. For registration 
details, call the Candle 
Education hotline today 

at (213) 442-4075. 


Hyatt Regency Hotel 
Bethesda, Maryland 
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utomated 
perations 


Taking the industry by storm! 


Automatic Management of Tape Drive Availability. 

Automatic Management of predetermined Initiator Availability. 
Automatic Interception of JCL-ERRORs and ABENDs. 
Automatic Interception of "NOT CATLG-2' Type Errors. 
Automatic Interception of Maximum Return Code Errors. 
Automatic Detection of Librarian, Panvalet, or PDS Libraries. 
Automatic Prompting for Required JCL or Data Changes. 


Automatic Holiday Adjustment (Optionally by Country). 
Automatic Critical Path Job Stream Support Through Priorities. 


Automatic Interface to any Restart System (e.g. CA-11). 
Automatic Initial Build and Daily Maintenance of Job History. 
Automatic JCL or Data Changes based upon day-of-week. 
Automatic JCL or Data Changes based upon week-of-month. 
Automatic JCL or Data Changes based upon month-of-year. 
Automatic CPU Affinity for multiple CPU installations. 
Automatic Dependent Job Affinity (Better than CPU Affinity). 
Automatic Required Dataset Validation & Job Triggering. 
Automatic Support for Exclusive Use of In-Use Datasets. 
Automatic Support to DUMMY JCL for Optional Datasets. 
Automatic Support to Skip Jobs Conditional on Datasets. 
Automatic ASF Comprehensive Security. 

Automatic SYSOUT Capture/Browse/ Archive (coming soon). 
Automatic Incident Reporting/ Problem Tracking (soon). 


Simplicity Personified! 
No New Concepts, Procedures, Editors, Techniques, etc. 
Full ISPF and ISPF/ PDF Implementation. 
ISPF Split-Screen (No Dedicated Terminals). 
Full Context Sensitive Interactive HELP. 
Run Documentation On-Line via ISPF/PDF. 
Uses ISPF/PDF EDIT to Define Scheduling Requirements. 
Schedule Commands or Jobs for Execution on a Future Date. 
Dynamic TSO/ISPF Multi-System Status Display. 
Support for 100’s of Duplicate Jobs/Commands per day. 
Interactive, Dynamic Calendar Creation & Maintenance. 
Separate Scheduling and Execution Controbs. 
One Single Daily Batch Job Supports All ASF Requirements. 
Dynamic *DEMAND* support for Jobs or Commands. 
Operator Console Interface for Multiple Command Lists. 
Optional External Security (ACF2, RACF, Top Secret, etc). 
Multiple "Independent" Separate Copies of ASF Per Processor. 
Multiple Centralized and Decentralized (End-User) Schedulers. 
Extremely low system overhead (typically less than 2%). 
NO System Hooks, NO mods, NO Exits, NO IPL Required! 
7-Day 24-Hour Support. -- 60-Day Free Trial. 


ASF 


"Designed for the ’90s" 


Chaney Systems Support 
W18180 Janesville Rd 
Muskego, WI 53150 
(414) 679-3908 
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—— Statistical Theory & Performance Data —— 


Statistical Theory from page 88 
time turns out to be .030, but CICS posts 
.5891. This represents a value outside of 
the predicted range. The increase in CICS 
response cannot be attributed to file re- 
sponse because the predicted value of .030 
was realized. Therefore, the problem must 
be attributed to another source. Perhaps 
your CPU is peaking out or maybe a 
change in a CICS system parameter, such 
as AMAXT, has prohibited the system 
from taking advantage of the file re- 
sponse. Conversely, a value for CICS re- 
sponse that is under the predicted range 
would indicate a successful tuning effort. 
Now suppose that you predict a CICS 
response of two seconds, a value that ex- 
ceeds your service level agreement. With 
this prior knowledge at hand, you can take 
steps to prevent your prediction from 
coming true. You may also use the linear 
equation in reverse answering the ques- 
tion, ‘‘What file response will give me 
unacceptable CICS response?’ This is 
accomplished by solving the equation 
for X: 


Where: 


X =File response mean 

Y =Hypothetical CICS response = 2 secs. 
B =.3931146 

M =25.596342 


Using your data and a hypothetical, un- 


acceptable value of two seconds for CICS 
response you get: 


2 — (—.3931146) 


X = 
25.596342 
oe 2 + 3931146 
x 25.596342 
X = 0934944 


This tells you that an average file re- 
sponse of .0935 will deliver a mean CICS 
response of two seconds. 


Conclusion 


The material that is covered here is only 
meant to serve as an introduction to sta- 


tistical theory as it applies to predicting 
performance. It must be realized that the 
relationship between file I/O times and 
CICS response is but a fraction of the fac- 
tors that must be taken into account. 
However, by considering the relationships 
between the six previously mentioned 
system parameters and using the statisti- 
cal theory presented here, one can chain 
together a series of equations that will 
closely represent your system. 

Using this, you can accurately predict 
any one or all of the six performance pa- 
rameters that define your system. These 
equations should be recreated every 
month. Any alteration made on your sys- 
tem changes the relationships between the 
parameters, rendering your equations in- 
valid. Certainly not all factors concerning 
system resources and performance are lin- 
ear. However, considering the time frames 
being used relative to the data, the con- 
fidence interval being used and the proven 
correlation, any error is adequately com- 
pensated. It is convenient that the calcu- 
lations are based on data collected over a 
monthly period of 30 daily observations, 
as fewer than 30 observations would dic- 
tate the use of another set of equations 
and tables. 

Finally, I have used this technique over 
the past two years and find it to be useful 
in determining what part of the system 
requires tuning (that is, CICS system pa- 
rameters, disk I/O subsystem), as well as 
determining the effects of new hardware 
acquisitions both before and after their in- 
stallation on the system. Also I have found 
it easy to implement the calculations on 
a Statistical calculator. This allows, after 
entering the data, retrieval of the corre- 
lation coefficient, the linear equation, the 
standard deviation and even the predic- 
tions with only a few keystrokes. You may 
also implement the equations on your 
computer either by writing the programs 
yourself or using Lotus, SPSS or SAS 
making statistical analysis even easier. = 
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Capacity Planning 


Capacity Planning from page 57 


Comparison of Application Feedback and Workload NBU 


BY APPLICATION AND FACILITY 
APPLICATION = PARRS FACILITY = ROS 


Ww 
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medical facility and each installation 
granule (unless the granule is the facility 
as a whole). 

To capture the Actual (versus Forecast) 
NBU data, we ensure that for each major 
AF installed, a corporate data source can 
be found of how many NBUs caused work 
for that AF. This provides data for updat- 
ing the capacity planning database and 
avails feedback by which forecasts are 
tuned. 

For instance, to provide the Actual 
WNBUs for PARRS, ADT and the three 
MRMS AfFs, the ADT system reports the 
number of admissions for each medical 
facility and the medical statistics system 
reports the number of outpatient visits and 
X-ray visits for each facility. 

Additionally, MRMS periodically re- 
ports the number of medical record sign- 
ins and so on. PARRS reports the number 
of appointments booked. These real-world 
feedbacks of the application’s workload 
are the sort of metrics that the NBUs are 
supposed to track. If NBUs are plotted 
against real-world feedbacks, the shape 
(but not necessarily the magnitude) of the 
two curves should match reasonably well. 
Figure | illustrates this for one of the 
medical facilities served by PARRS. The 
triangular data points show the ‘‘patient 
visit?” WNBU and the square ones show 
the “‘patient appointment’’ feedback, the 
work that PARRS actually did. Note that 


MAINFRAME JOURNAL 


TRIANGLE = WORKLOAD NBU 


the NBU is forecast into the future but the 
feedback is not. (The numbers on the Y- 
axis have been altered for this article.) 

The major difference between NBUs 
and feedbacks such as appointments is that 
we currently have no reasonable basis for 
forecasting the feedbacks; we do for the 
NBUs. After a few years’ feedback data 
have been accumulated, it is entirely pos- 
sible that this will become susceptible to 
reliable forecasting. If this comes about, 
it may be a wise decision to switch over 
to using this ‘‘new’’ WNBU for capacity 
planning henceforth. 

In summary, the crucial point is that 
application developers must contribute to 
the capacity planning process by finding 
and accounting for business events called 
NBUs that will relate in a linear fashion 
to computer resource consumption. 

In the next issue, I will describe the 
capacity planning database in detail, give 
some examples of its use and relate some 
hard-earned practical experience. = 
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Nothing Else Like It Anywhere! 


Dynamic Job Class Enforcement by User-id/Jobname. 
Dynamic JOBCAT/STEPCAT Restriction and Authorization. 
Dynamic WTO Message Processing Subsystem. 
Dynamic Console Message Suppression. 
Dynamic INTRDR Restriction and Authorization. 
Dynamic Accounting Number Validation and Verification. 
Dynamic Addition of TIME = to Job Cards by Class. 
Dynamic Validation of TAPE usage by Job Class. 
Dynamic Addition of EXPDT = for TMS (CA-1) environments. 
Dynamic Validation of BLP usage by Program Name. 

ic Operator Commands Triggered by Any Message. 
Dynamic JES2 Remote Start, Stop, & Status Messages. 
Dynamic DASD Allocation Redirect via UNIT = Substitution. 
Dynamic Volume Affinity Enforcement by USERid/ GROUP. 
Dynamic DASD Block Allocation Compatibility Support. 
Dynamic CPU & WAIT Time Extension for Production Jobs. 
Dynamic MSGCLASS = Addition for TSO Submitted Jobs. 
Dynamic Job Start/End Notification for TSO Users. 
Dynamic Placement of Step Return Codes on Joblog. 
Dynamic NOT-CATALOGED-2 Interception & Notification. 
Dynamic DASD Device Block Counts by DDNAME. 
Dynamic Addition of Distribution Code on Separator Page. 
Dynamic Adjustment to BUFNO =1 for VIO requests. 
Dynamic TSO User Job Failure Notification. 
Dynamic Job Identification with RACF and TSO/E Systems. 
Dynamic Elimination of Predefined Messages from Hardcopy. 
Dynamic Highlighting of Installation Specified Messages. 
Dynamic TSO Redirect (ECHO messages to TSO User). 
Dynamic Cancellation of Jobs Issuing Msgs (IEF 2871). 
Dynamic Reply to WIT ORs Providing Greater Automation. 
Dynamic CICS Journal Offload and Validation. 
Dynamic SMF Dataset Offload. 
Dynamic Production-Job Failure Notification (Abends, 
JCL-errors, Return codes (non-rollable highlighted messages). 
Dynamic Authorization Support for Installation Written 
Programs Validates Caller by Location (LPA/CSA or Region). 


Don’t Write Another MVS Exit Again! 
Dynamic Changes to DSS Specifications (no IPL). 
Dynamic Loading of SMF, DFP, & TSO Exits (No IPL). 
Dynamic Interception of Abends in System Exits 
(No Job or System Failure if/when an Exit Abends). 
Dynamic Support for Multiple Concurrent Exit Modules 
( 2IGGPRE0s, 5 IEFUJIs, 3 IEFACTRTs, etc). 


Specialized Support Utilities Included! 


IPL Volume Space Compression Eliminates SMP X37 Abends. 
Real-Time Update of DSCBs (Allows Rename Even if In-use). 
JCL Reformat Validation Utility which Supports User Exits. 
Dynamic DASD Space Reclamation and Reporting Utility 
Scratches Work Datasets, Compresses PDSs, Releases Unused 
Space, Migrates non-current GDG datasets (if DFHSM is 
installed), and Reports on Uncataloged/Miscataloged Datasets. 
MVS Support for VM/CMS File Structures Simplify Conversions. 
Convert multiple CMS Files to MVS PDS members by File-type. 
7-Day 24-Hour Support. --- 30-Day Free Trial. 


"The Dynamic 
Support Subsystem" 


W18180 Janesville Rd 
Muskego, WI 53150 
(414) 679-3908 
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CheckOut/VM Provides 


Higher System Availability 
Duquesne Systems (Pittsburgh, PA) 
recently introduced CheckOut/VM, a 
software product that verifies the avail- 
ability of both hardware and software 
components in a VM system configu- 
ration. It is designed to provide higher 
system availability by automatically 
probing the VM system for down com- 
ponents, restarting the down compo- 
nents it finds and notifying designated 
support staff of component failure. 


For more information 
CIRCLE #200 on Reader Service Card 


ADMS Reduces Time 
To Construct Data 


Management Requests 
Advanced Software Products Group 
(Naples, FL) has announced Automated 
Data Management System (ADMS), a 
system said to drastically reduce the 
amount of time necessary for construct- 
ing data management requests. All re- 
quests are transmitted on-line through 
TSO/ISPF screens. It also provides the 
ability to transmit, print, confirm and 
view historical request data. ADMS 
supports the MVS operating system. 


For more information 
CIRCLE #201 on Reader Service Card 


Personal REXX 2.0 
Available 


Mansfield Software Group (Storrs, 
CT) has announced Personal REXX 2.0, 
a major upgrade to their REXX lan- 
guage processor for the IBM PC, PS/2 
and compatibles. Personal REXX is the 
first full PC implementation of VM’s 
acclaimed REXX programming lan- 
guage. Major enhancements in 2.0 in- 
clude improved performance with some 
REXX programs running twice as fast; 
and increased storage capacity so that 
Personal REXX can use all available 
memory below 640K as well as EMS 
expanded memory. 


For more information 
CIRCLE #202 on Reader Service Card 


Best/1 I/O Diagrammers 


Pinpoint System Bottlenecks 

BGS Systems (Waltham, MA) has 
announced the BEST/1 I/O Diagram- 
mer for MVS and for VM. These two 
self-contained products are designed for 
systems and operations personnel re- 
sponsible for managing and tuning 
DASD I/O subsystems. With these 
standalone I/O Diagrammers, main- 
frame installations can quickly and eas- 
ily find out what is going on in their 
DASD systems. They can draw their 
I/O configurations and identify which 
are the ‘‘hot’’ or high utilization de- 


vices representing bottlenecks that are 
prime candidates for tuning. Standard 
MVS and VM data sources are used as 
input. 
For more information 
CIRCLE #203 on Reader Service Card 


CPMS/SYSD Accesses And 


Controls JES2 Printers 

H&W Computer Systems’ (Boise, ID) 
CPMS/SYSD Release 6.1, the CICS- 
based productivity tool, features ISPF/ 
PDF-like edit/browse, SDSF-like re- 
port viewing/routing, CICS/JES2 printer 
management and CICS debug/manage- 
ment utilities. With the new JES2 printer 
display, authorized users can access and 
control JES2-driven departmental print- 
ers. LISTVTOC and LISTCAT utilities 
now feature indexed VTOC and ICF 
Catalog utility support. 


For more information 
CIRCLE #204 on Reader Service Card 


DB2-XPERT Assists DB2 


Application Development 

XA Systems (Los Gatos, CA) has an- 
nounced DB2-XPERT, a mainframe 
software productivity tool designed to 
assist DB2 application development. 
DB2-XPERT provides capabilities to 
edit, browse, extract and load DB2 ta- 
bles under TSO/ISPF. It runs as a dialog 
under ISPF using menu-driven, ISPF- 
like displays and a command set very 
similar to ISPF. 


For more information 
CIRCLE #205 on Reader Service Card 


VSAMVIEW Selects 


Optimal Parameters 

Design Strategy’s (New York, NY) 
VSAMVIEW uses catalog and user- 
supplied information to select optimal 
parameters for a new or existing VSAM 
cluster. Clusters can be tuned for im- 
proved performance or space utiliza- 
tion. Menu screens are similar to those 
within ISPF. New features in Version 3 
include: list volumes containing VSAM 
files and/or suballocated space, list user 
catalog aliases, and list VSAM clusters 
on a specified volume. 


For more information 
CIRCLE #206 on Reader Service Card 


VTAM-EXPRESS 
Eliminates Separate 


Compression Product 

SofTouch Systems (Oklahoma City, 
OK) recently announced VTAM-EX- 
PRESS that performs terminal data- 
stream compression at the VTAM level. 
No longer is a separate compression 
product for each different VTAM ap- 
plication needed. Both inbound and 
outbound compression is provided for 


DB2/Batch Cures Batch 
DB2 Blues 


NY) DB2/Batch is said to cure many of 
the problems caused by abends in DB2 
batch programs masked by the TSO 
Terminal Monitor Program and DSN 
command. DB2/Batch solves these 
problems by letting you run your DB2 
programs directly in batch with conven- 
tional JCL. With the product, batch DB2 
programs can reportedly work compat- 
ibly with job scheduling packages and 
multi-step jobstreams, as well as with 
Checkpoint Restart and the abnormal 
disposition of datasets. 


MVS Users Get LOADLIB 
AUDIT 


ester, IL) recently announced LOAD- 
LIB AUDIT for MVS. It produces re- 
ports from detail analysis and content 
cross referencing of an executable pro- 
gram library. With LOADLIB AUDIT, 
the detail content and structures of a 
library are exposed and processed, pro- 
ducing very enlightening information. 


every application in the network. 


For more information 
CIRCLE #207 on Reader Service Card 


EXPLICIT Analyzes 
Mainframe And 
Network Operation 


Technetronic’s (McLean, VA) EX- 


PLICIT is said to provide an easy, pain- 
less method of analyzing the operation 
of your IBM mainframe and network. 
Its automated data gathering features, 
its modern mouse and menu interface, 
and its PC-generated color graphs make 
it a unique integrated performance man- 
agement and capacity planning tool. 


For more information 
CIRCLE #208 on Reader Service Card 


SAS/CPE Start Set 
Combines Tools 


SAS Institute (Cary, NC) is provid- 


ing a faster and more efficient way to 
handle Computer Performance Evalua- 
tion (CPE) applications with the SAS/ 
CPE Starter Set. Available under the OS/ 
MVS operating system, the SAS/CPE 
Starter Set is a menu-driven facility for 
evaluating SMF and RMF data — com- 
bining many of the SAS system’s data 
management, analysis and reporting 
tools into a packaged CPE solution. 


For more information 
CIRCLE #209 on the Reader Service Card 


Relational Architects’ (New York, 


For more information 
CIRCLE #210 on the Reader Service Card 


D. L. Brickey & Associates (Roch- 


For more information 
CIRCLE #211 on the Reader Service Card 
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INTRODUCING THE FIRST REAL-TIME 
MONITOR FOR CSA. 


Caer bas _— ALLOCATED 


ARAMA LAADDA MOLL © 1000000 


Introducing the new Common Storage 
Monitor for RESOLVE PLUS, the first in-depth 
tool for monitoring users of CSA and SQA on 
MVS/XA. And the most effective way to reduce 
time consuming, and costly, IPLs caused by 
common storage constraints. 


Control CSA creep. 

Common Storage Monitor helps you control 
“CSA creep”, the slow, hidden increase in 
common storage allocation that can ultimately 
result in system degradation and even failure. It 

is the only monitor that allows you to account 
for common storage usage by individual user. So 
you can identify applications that are abusing 
common storage and recover wasted CSA held 
by terminated tasks. 


Pinpoint CSA usage. 

Common Storage Monitor displays allocated 
storage for each address space by job name. 
Operating in either ISPF or command mode, 


you can display as much detail as you need to 
identify the user responsible for the allocation, 
and to analyze how the storage is being used. 

Password-protected RESOLVE PLUS services 
are also provided to free areas of CSA once they 

have been identified. Online color charts give 

you an easy-to-interpret overview of common 
storage allocation. 


For more information on the Common 
Storage Monitor for RESOLVE PLUS Version 
3.0.0, call Marty Johnson today. In California: 
800-624-5566. Outside California: 800-822- 
6653. Boole & Babbage, Inc. 510 Oakmead 
Parkway, Sunnyvale, California 94086. 


Boole: , RY 
Babbage oh) 


International sales and support provided through The European 
Software Company and a worldwide distribution network. 
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Altai Software: The Experts In Data 
Center Automation 


esigning software that enables a 
D computer system to run itself is 

the objective of Altai Software, 
an Arlington, TX based software com- 
pany specializing in data center automa- 
tion products for the IBM mainframe en- 
vironment. 

Altai’s two main products — Zeke, 
“The Scheduler that Works,”’ and Zack, 
“*The Operator’s Operator,’’ provide data 
center operations personnel with the tools 
necessary to automatically schedule and 
operate IBM’s VSE and MVS operating 
systems. 

‘*Teaching the computer to run itself is 
our mission,’ says James P. Williams, 
president of Altai. ‘‘It is just not practical 
to expect people to keep up with these 
giant beasts and effectively schedule, op- 
erate and manage them.”’ 


Broad Scope of Automation 


Altai’s view of the problems of data 
center automation may be broader in scope 
than that of other vendors. Instead of fo- 
cusing on VSE or MVS, Altai sees the 
problem of automation to be one of au- 
tomating the IBM mainframe data pro- 
cessing environment. Altai’s solutions for 
automated operations are applicable to 
both VSE and MVS, just implemented 
slightly differently. 

‘‘Conceptually, both operating systems 
have the same problems that relate to au- 
tomation. In fact, many companies have 
a mix of installations running VSE and 
MVS and are therefore looking for a 
product that provides a solution for both 
operating systems — one that solves the 
problems of automating data process- 
ing, not just MVS or VSE,’’ Williams 
points out. 


First Product — Zeke 


Altai’s first product, Zeke, was first in- 
stalled in June of 1982 at Henkel Corp. 
(now ITG Corp.) in Minneapolis, MN. 
“‘Our first two installations in June of 1982 
were both converting from NCR ma- 
chines to IBM mainframes. They were 
used to having a scheduling system and 
did not want to implement their IBM sys- 
tems without one. We installed Zeke in 
each of those accounts and they are still 
running Zeke today — although both have 
since migrated from VSE to MVS,”’ Wil- 
liams says. 

Altai began distributing products inter- 
nationally in 1983 with about 34 percent 


James P. Williams, president 


of its revenue now being generated by 
international sales. ‘‘We have had good 
results internationally with France being 
our great success story. We have more 
than 100 Zeke and more than 50 Zack 
installations in France. This has hap- 
pened for two reasons — the quality of 
our products and the caliber of our French 
distributor, Faster SARL,’’ Williams ex- 
plains. 

In 1987, Datapro Research Corp. con- 
ducted a user survey as part of its eval- 
uation of Zeke. That survey rated Zeke 
higher than any other scheduler on the 
market in terms of customer satisfaction. 
Today, about 600 installations worldwide 
use Zeke to automatically schedule their 
computer operations. 


Zack Gains Quick Acceptance 


Altai’s second product, Zack, is rela- 
tively new, having been generally re- 
leased in January of 1988. Zack auto- 
mates console operations for both the VSE 
and MVS operating systems. Zack allows 
you to program console operation using 
a REXX-like language. Zack can auto- 
matically respond to and suppress routine 
console messages. In addition, Zack can 
issue system commands or messages at 
predetermined times, call user-written 
programs and perform many routine 
functions faster and more accurately than 
ever before possible. 


‘“‘This frees operations personnel for 
handling the exceptions to the rules. As 
console message rates continue to in- 
crease, it will become more and more dif- 
ficult for human operators to keep up. 
Zack can be a valuable aid,’ Williams 
points out. 

Altai has sold more than 120 Zack sys- 
tems since the product’s introduction. 
“The quick acceptance of Zack in the 
market surprised us. However, Zeke and 
Zack together make a powerful team and 
a large percentage of our Zack sales have 
been to existing Zeke clients. This dem- 
onstrates the degree of loyalty Altai’s 
customers feel toward the company. We 
listen to them, we react to their needs and 
we support them. That is why we are still 
here,’ Williams comments. 

Altai users meet regionally four times 
a year to share their experiences and to 
inform Altai of their needs. At each 
meeting, the users vote on suggested 
product enhancements, thereby prioritiz- 
ing their needs for the company. **About 
80 percent of the product enhancements 
we have made to Zeke have been user 
suggestions,’ Williams says. 


Upcoming Products 
and Enhancements 


Altai has several new products and ma- 
jor enhancements to existing products 
planned and in development. Upcoming 
versions of Zeke and Zack will provide 
scheduling and management for a net- 
work of mainframes, including mixed 
MVS/VSE environments. Zeke/VM_ is 
scheduled for release during mid-1989. 

Altai’s newest product, Z/CAT2, is a 
utility that prevents NOT CATLG 2 and 
duplicate dataset errors from occurring 
under MVS. Z/CAT2 is currently in Beta 
test sites and will be available for general 
distribution on March 1. Altai is also de- 
veloping a restart/rerun management sys- 
tem that will enter the early testing stages 
in March. Additional products are planned 
to further expand Altai’s family of data 
center automation software. 


Key to Success 


Williams says that a key to Altai’s suc- 
cess has been its concentration on a single 
area of expertise: data center automa- 
tion. ‘‘We aren’t trying to be the biggest, 
just the best at what we do,’ concludes 
Williams. = 
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Lee Veal On VSE Console Support... 


“Anything IBM gives you, DOCS 
makes five to ten-fold better.” 


™ 


With 17 years systems software experience, Lee Veal, 
Software Support Supervisor for The City Of Garland, 
Texas, has seen a lot of software come and go. But there’s 
one product Lee won’t let go— DOCS (Display Operator 
Console Support) from SMARTECH Systems. And 

here’s why... 


| recommended DOCS because it looked like it was going to 
save us a lot of money. With the ability to call up the VSE 
. system console from multiple terminals, we're able to 
} de-centralize our access. And that cuts down on the 
phone calls received by the operational staff, because 
/ ull programmers have access to DOCS in their building 
...and at home. 


How easy it is to install DOCS... 


It’s not like re-inventing the wheel to bring DOCS 
up. You don’t have to change your operational 
layout or procedures just because DOCS is in 
place. In fact, it actually makes the system come 

up faster. 


Plus DOCS allows the terminals to be shared back and 
“4 forth between CICS or any other on-line software. They 
_» can be dual purpose —and we need those terminals for 
other functions. 


On DOCS security features... 


DOCS allows us to use password securities and “read only” 
type securities whenever the DOCS consoles come up. We 
can even include or exclude partitions on each individual con- 
sole. We use these features in the programmer area—for the 
terminals that the programmers have access to. 


How DOCS Dynamic System Status Display (DSSD) 
increases efficiency... 


It tells us if a job is running or why it stopped. This makes a 
difference when we have a problem. We can know what the 
program is waiting on and address the problem saving us a lot 
of time. If we didn’t have this, we’d be “flying blind?’ 


How DOCS reduces keying time... 


With DOCS we're able to set up our PF-Keys on-line to 

store commonly used responses like IGNORE, CANCEL and 

RETRY. Also, there are features that let us “pre-answer” ques- 
SMARTECH SYSTEMS, INC. perio One we peutemats than any is the Bey mere — 

. : 3 where you can call back your previous reply and answer that 
Turning high technology into SMART TECHnology.™ same thing again for the next response. Plus, we have the 
10015 W. Technology Bivd., Dallas, TX 75220 ability to recall any line on the screen for input. It saves the 

Telex: 9102503110 operators time from sitting and pecking out those characters. 


On the need for DOCS in today’s environment... 


It simply makes your operation run easier with it than without it. 
Most of the benefits of DOCS you really can’t say in words how 
good they are— you just have to experience it. 


Why not experience it for yourself? Try DOCS FREE for 
30 days. It takes just 30 minutes to install. Call us for 
more information. 


VSE ~ roel mt —— i of the perth bre glare Machine 1-800-53-SMART 
Corp. H and D are trademarks of SMARTECH Systems Inc. . 
Copyright © 1988 SMARTECH Systems, Inc. All rights reserved. Outside the U.S.., call (214) 956-8324 
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” Without the CPU Overhead | 


IAM REDUCES THE SIZE OF YOUR VSAM FILES BY 30 TO 70% 


'S Fl STRUCTUI Ee — SAVES 20 TO 40% 
IAM uses an raceanced file structure which is far superior to 
VSAM. IAM's supercompressed index, freespace concepts and 
blocksizes make much more efficient use of disk space. 


SAVES AN ADDITIONAL 20 to 50% DASD SPACE 

Most files contain records with unused fields or repeating sets of 
characters. When IAM applies its proprietary compression tech- 
wisi he result is an additional 20 to 50% reduction in file size. 


a fact, since SIAM S CPU time is 
noinally Which less than VSAM, IAM with data compression 
takes less CPU time than normal VSAM processing. 


Online systems (CICS), BATCH jobs, TSO, SMP/E and other appli- 


cations make extensive use of key indexed VSAM (KSDS) files. 


IAM is a transparent alternative to VSAM KSDS files, which sub- 
stantially reduces the impact of VSAM processing in your instal- 
lation. There are no modifications to programs or JCL to use IAM 
files in a of VSAM. 


IAM takes the. guessing game out of VSAM 5} space ‘allocation. 
Large amounts of disk space are wasted when users 
overestimate how much space VSAM requires or 
how many records a file will contain. VSAM 
cannot release overallocated space. 


SPACE 
SAVINGS 


The Incredible 


